With the bookmarks query, is there a reason we don...

# confetti

[yschimke]

With the bookmarks query, is there a reason we don't use Connections?

[yschimke]

Currently we need to merge with some other source of the data.

[yschimke]

Current query

query GetBookmarks {
    bookmarks {
        sessionIds
    }
}

[yschimke]

cc @mbonnin

[mbonnin]

Mmmm no strong reason, just me lazy enough to implement pagination

[mbonnin]

Also I don't think it's paginated in the backend. IIRC, the list is read and rewritten every time

[mbonnin]

Not sure if it makes sense to add pagination there?

[mbonnin]

Or do you mean something by Connections? (I'm thinking Relay Connections)

[yschimke]

Yep, same one.

[yschimke]

But more that the query doesn't end in List<String>, you can define exactly the data you need.

[yschimke]

So could be either nodes pointing at SessionDetails, or effectively projecting to a List<String>

[yschimke]

I'm going to end up doing n+1 queries, but assuming that the n is cached already, so cheap.

[mbonnin]

So more like so?

type Query {
  bookmarks: BookmarkConnection
}

type BookmarkConnection {
  nodes: [Session!]!
}

[mbonnin]

I can do that, makes sense to me

[yschimke]

Yep.

[yschimke]

I'm not blocked, so no rush at all, just will simplify the wear app.

[mbonnin]

Should be live in a few minutes

[mbonnin]

https://github.com/joreilly/Confetti/pull/547

[yschimke]

OK, I'm impressed!

[yschimke]

very, very simple.

[mbonnin]

Yea, graphql-kotlin is pretty cool to get started with. Not 100% how good it scales though

[mbonnin]

But for someone like me that's pretty new to backend dev, it's pretty cool being able to write Kotlin and have it available in the API automagically (i.e. using reflection)

[mbonnin]

Would like to investigate https://github.com/xuorig/chromatophore at some point to handle the deprecation lifecycle a bit more smoothly