When observing from the cache, is there some guara...

# apollo-kotlin

[Stylianos Gakis]

When observing from the cache, is there some guarantee as to in which order the items will be emitted to me?
I am trying to see if they will just be returned to me in the same order in which they were added to the cache or not.
I think the proper approach might be that this item is sorted by me right after getting a cache emission, doing a sortedBy myself, but would be good to understand how the cache determines the ordering itself.

[mbonnin]

It's really hard to reason in terms of "order" there. By default requests can run in parallel in different threads, including watchers.
What defines "something is added to the cache"?
• Is it by the time the SQL query returns (that's not visible to the caller)
• Is it by the time the caller has received the response that was just written

[mbonnin]

It's all channels under the hood so the order is preserved but trying to synchronize the query that made the initial cache write and the watcher is hard

[Stylianos Gakis]

Yeah that makes total sense. I would also expect it to not be the right place to assume any ordering to happen, and that can just happen in user-land after we get the cache emission.
One thing that one could do querying from SQLDelight for example would be to embed the ordering part in the query itself, but in our scenario doing any such logic at that layer would not make sense right?

[mbonnin]

Not sure I follow. Use case is adding a chat message or something like so?

[mbonnin]

In those cases, I think you need to write the full list in the cache? Then the order is determined by the writter, not the reader?

[Stylianos Gakis]

Yeah this is about chat messages.
Actually you are right, since we even control writing to the cache entirely ourselves here, I could ensure that the ordering is done here https://github.com/HedvigInsurance/android/blob/ba69a697a6a38147da88510f53d08d2b10[…]tlin/com/hedvig/android/feature/chat/data/ChatRepositoryImpl.kt if I sort them. Then the reader will not need to sort it each time themselves. Instead of doing it on the watcher part of this https://github.com/HedvigInsurance/android/blob/ba69a697a6a38147da88510f53d08d2b10[…]tlin/com/hedvig/android/feature/chat/data/ChatRepositoryImpl.kt

Theoretically however, the amount of times we write and the times we read should be that we more often write than read, since some writes could result in no changes to the cache, aka no need for watch to emit again, if it does that in the first place at least instead of always emitting.

[mbonnin]

It's almost philosophical at this point 😄 . I like to see my cache state as self-contained/side-effect free. Adding ordering in the mix kind of taints that a bit

[mbonnin]

But then philosophy might have a cost if you end up rewritting a lot

[mbonnin]

Same as functional vs imperative programming

[mbonnin]

I'm guessing the "good" answer lies in avoiding the rewrites at the low level or so, same as what compose is doing with recomposiition?

[mbonnin]

Hope that makes sense, sorry, it's a bit abstract 😅

[Stylianos Gakis]

Yeah what I gather from this is:
• Keep cache just as a cache. Put the messages in there, and rely on the unique ID to keep the entries unique everything. No logic here.
• Then since my UI specifically wants those messages, but it wants them sorted, then my repository can take the cache as-is, and assume nothing about how it stores things, and do the sorting itself before sending this list over to my presenter.
Am I in the same philosophy space as you with this one, what do you think? 😄

[Stylianos Gakis]

Because re-writting the items to the cache, I can’t avoid that. Every X seconds, (since we got no subscription to the backend) we poll for new messages, and whatever the backend returns we push into the cache as they are. And rely on the IDs to make sure that the cache is not growing unnecessarily.

[mbonnin]

I think we are in the same philosophers space 😄