I am experimenting with androidx.paging and I was ...

# apollo-kotlin

[Stylianos Gakis]

I am experimenting with androidx.paging and I was looking at the idea of not bringing Room into the mix, but instead use apollo's cache as the "database" where the single source of truth of the data shown in the pager comes from.
Obviously Room comes with the convenience where you can grab a query and make it return a PagingSource automatically for you. Has someone ever tried to do the same for the GQL cache?
Optimally if someone else has already done something similar I could take a look to see if I can use it, otherwise I am just getting into it to see how it might even work.
p.s. Never used androidx.paging before, so I am very much in uncharted land right now 😅 Please tell me if what I am saying is a bad idea for some reason.

[Stylianos Gakis]

From my very basic idea of how androidx.paging works right now. My thought is to have the GQL cache be the SSOT. A RemoteMediator should do the network requests when there is a need to fetch more, and as a consequence update the cache, which the PagingSource should be observing, and that should then automatically get to see the new information.
Again, I am still in the "I think this is how it works" stage, so looking to hear if someone else has done smth similar too 😅

[bod]

I experimented with this a while ago, in Confetti. Note that it uses the pagination support that’s in the incubating version of the normalized cache.

[Stylianos Gakis]

Oh boy, I feel like I am biting more than I can chew here reading the docs about relay etc 😄
Our backend API does not use nodes + connections etc.
It has an API like:

type Conversation {
  messagePage(olderToken: String, newerToken: String): ChatMessagePage!
}

type ChatMessagePage {
  messages: [ChatMessage!]!
  olderToken: String
  newerToken: String
}

Now trying to understand if this would still be applicable here 😄

[Stylianos Gakis]

I could always also go the other approach I think, to not use the cache as the SSOT and just put things in a Room DB, and have that give me a PagingSource. With the caveat that my RemoteMediator do the networking and manually store in Room instead of relying on the caching that apollo does for us. Right?

[bod]

I think that would work yes 👍

[bod]

If you want to use the Apollo cache as the SSOT, I think you'll have to merge records together - which is where the incubating stuff can help (but can also be done manually with the ApolloStore API).

[Stylianos Gakis]

Since I see that what you are linking is mentioned as "incubating", I assume these APIs are to be worked on after the full release of 4.x right? Have you been working on those recently? Do you have many people asking for it?
And from your idea of the state of the project right now, would you feel like this incubating artifact is far from being done and might change a lot or not?
Just trying to see how I can make the best decision for what approach I should go with here 😄

[Stylianos Gakis]

I am at least somewhat familiar with some of those cache APIs, used here https://github.com/HedvigInsurance/android/blob/a91cfe7de84fae0f5f1d4ccb11ab3623ed[…]tlin/com/hedvig/android/feature/chat/data/ChatRepositoryImpl.kt which came from a previous discussion I've had in this channel. I assume you'd mean something similar to this would have to be done inside the RemoteMediator right?

[bod]

> I assume you'd mean something similar to this would have to be done inside the RemoteMediator right?
Yes exactly 🙂

About the incubating artifacts: although we'd love to get feedback on them, they're not ready for production. And you're right, we'll focus on the cache in general after the 4.0 release.

[Stylianos Gakis]

Alright that sounds good, thanks for being honest about it. I think my best bet is to fiddle a bit with doing this without the incubating artifact, since we want this to be used in production quite soon. Then if this proves to be too tricky I might see how Room might be able to help instead.
And after we also migrate to 4.x I might be able to give those APIs a try too. I know it's super useful to get people to try them out to get good feedback. I am always looking at the release notes, so if I see anything related to this there I might be back here with more questions 😅

[Stylianos Gakis]

If anyone stumbles upon this thread, a little update.

For now I just went with androidx.Room as my SSOT (soon it'll be KMP-compatible too so that's good), and on my GQL calls I just pass in the combo

.doNotStore(true)
.fetchPolicy(FetchPolicy.NetworkOnly)

So as not to use the cache at all for this since it'd be wasted and I got my POC working just fine.

My RemoteMediator now is responsible for calling the GQL Endpoint and storing the things manually inside my Room DB where I also get full control over the type of data I store as opposed to what specifically our backend is returning.

Works fine, I am not utilizing the entire power of apollo-kotlin for this but this is fine, it did give me the tools to get this working anyway, so I am happy 😊 Thanks for the help, and again if I revisit this later I will definitely come back here 😄

[bod]

Thanks a lot for the followup 🙏