search

kitten / pessimism

A fast HAMT Map intended for KV caching and optimistic updates
MIT License
15 stars 3 forks source link

How to handle sequential optimistic results? #5

Closed wmertens closed 4 years ago

wmertens commented 4 years ago

I'm evaluating urql and I wonder how the normalizing cache could handle multiple in-flight optimistic requests?

Explanation and more discussion https://github.com/apollographql/apollo-client/issues/3691

kitten commented 4 years ago

Hiya, sorry! Didn’t see this question since I wasn’t watching this repo. This is probably more of a question for Graphcache btw.

Practically speaking, every field in the store is treated separately and optimistic values will stack, but I see your point, once a real result comes in the server result may differ from what it should be.

Now, there are several ways to address this, but I don’t think the approach you’re describing in the issue is quite safe.

The problem is that on any entity or field we may disagree with the server, but the server is always right, since it’s our source of truth.

If we imagine a counter like the one you’re describing, then we may get results back that will decrement the counter again; and that’s perfectly correct! Once the server gives us a result, we have to trust it.

This obviously becomes a problem when you actually want to stack mutations, which can be quite dangerous. But in that case, my opinion is that a batching and/or queueing layer should be in place. In essence, I think this is more of a problem with scheduling than with optimistic updates.

This is a really contrived case I suppose, but I do believe that in real-world apps this would behave quite differently. We can’t tell in what order the mutations come back. When the connection is quite unstable we may even get a bigger number back then a lower number in the case of the counter, so this needs to explicitly be queued.

But since those counters are rare in apps, I think that it’s a UX + batching problem. Of course, we haven’t worked on batching yet, but that may change soon 😅

kitten commented 4 years ago

Not sure if it’s worth updating you on this, but we made some great breakthroughs on this 👏

Graphcache is now not using pessimism anymore, first of all; but the Optimistic Layers have become a lot better.

Graphcache makes an effort to keep results commutative. Query results are applied in the order they were sent in. This greatly increases consistency in the face of network latency or inconsistent response times.

This change has been ongoing for a while now and is well tested now as far as I can tell.

Soon we’re shipping this, which has just been merged: https://github.com/FormidableLabs/urql/issues/747

This makes the application of optimistic updates more intuitive and consistent.

It basically guarantees that optimistic updates for mutations are completely separate from “real” updates. https://github.com/FormidableLabs/urql/issues/747

wmertens commented 4 years ago

Thanks for the update!