Hey, this is a more generic GraphQL question I sup...

# apollo-kotlin

[Stylianos Gakis]

Hey, this is a more generic GraphQL question I suppose, but here it goes. We’re planning to soon create our first endpoint of something that is supposed to be paginated. I’ve never really worked with paginated things coming from the backend through GraphQL, nor have the backend devs we got setup this for our GraphQL backend. I am trying to make as good of a decision as early on as possible in how we set this entire thing up, to make all of our lives easier.
I’ve given this a read, along with the apollo-kotlin docs on pagination with the sandbox spacex launches project, where the approaches taken seem to be a bit different (no edges on the tutorial). So I am trying to understand what parts of the tutorial are just omitted due to it being a simple tutorial, so we should also be careful not to make such mistakes for a production implementation. Or maybe in short, where can I read more about how to set this up properly, both for client and for the backend? And are you aware of any samples which I can look at to take inspiration from in order to do this?

[Stylianos Gakis]

Just as I was writing this, I figured that Confetti may have an implementation of this on the backend, and surely https://github.com/joreilly/Confetti/tree/main/backend seems to expose such an API with paginated results + edges and so on. Would you say this is a good place to start with this? I am looking into it now

[mbonnin]

I wouldn't use the tutorial as inspiration for pagination as its purpose is simplicity and not future-proofness

[mbonnin]

Confetti is a bit better with the huge disclaimer that I wrote the backend and I am mostly not a backend person 😅

[mbonnin]

All in all, I would say you can't really go wrong with Relay connections

[mbonnin]

I find relay myself a bit verbose and I like what GitHub is doing were they have Connection.nodes that allows you to skip Connection.edges and have the client code a bit more lightweight

[Stylianos Gakis]

Alright yeah my hunch of it being too simple was correct then, glad I am asking this then 😄

“Relay connections” is a framework for JS or something like that? Or is it just that the idea of how to structure the schema can be reused regardless on our own implementation anyway? Using netflix dgs on a spring backend here, so it’d be super nice to get a non JS focused article about it too 😅

Also what would be even more convenient is if someone already has a sample of how they use GQL based pagination with androidx.paging3, but maybe this doesn’t exist as open source at least.

In particular, we need to do this for a chat feature, so this also means that we’d also be interested in being able to subscribe to new messages, and I feel like this is going to be a much much bigger project than what I initially thought about 😅

[mbonnin]

"Relay" is Facebook's opinionated way of doing GraphQL. While the main client is for the web, the concepts (connections, nodes, ids, etc...) are pretty much framework agnostic

[mbonnin]

Ah, found the relay spec. This is what I intended to share initially actually

[mbonnin]

Also ping @bod. Did you have a paging3 GraphQL pagination exemple somewhere?

[Stylianos Gakis]

Perfect, the spec looks like a great place to look at. Along with the GitHub API which is definitely a production-level example we can look at.
I do wonder however for our need to do subscriptions as well, since it’s a chat, it feels like we’d either have to do a manual polling system to still be able to use the cursors etc in our queries, otherwise if we do a gql subscription I am not sure if those two things can work together well

[mbonnin]

Usually subscriptions do not return pages but more individual items as they appear

[mbonnin]

So you would do one initial paginated query to get the list and then open a subscription for the follow up items

[mbonnin]

This is prone to race conditions if a new message is sent in between your query and subscription. This has been one of the issues that @live or @stream (see here and here) have been trying to solve although none of them made it to the spec yet

[Stylianos Gakis]

Yeap, that’s why I am thinking that they wouldn’t “work together well” since using both is kinda bound to make it harder to work with.
I wonder if going all out on using the paginated results + a polling mechanism every (for example) 5 seconds is our best bet so that the client implementations will be much simpler too. And probably will intergrate with androidx.paging much easier too.

[mbonnin]

Depends how "real time" you want your chat to be I guess

[mbonnin]

5s can be long if you're waiting for that response eagerly 😄

[mbonnin]

One way to solve the "race condition" issue is to include the cursor in your subscription:

subscription GetMessages($after: String)

[Stylianos Gakis]

I know 😔 Maybe 3 seconds then 😅
In general, I don’t need to have our little app have as good of an experience as signal or whatever. It can be “good enough” if it means 80% less work imo. But that’s why I am having this conversation in the first place, to try and understand how we should approach this

[mbonnin]

Requires a bit more logic server-side but sounds doable

[Stylianos Gakis]

Hmm interesting yeah!

[bod]

I have an example here, using the GitHub API 🙂 But I haven't maintained it for a while. Interesting bit is here