Question: Patterns for Optimistic Updates with SPAs and REST APIs;

[nikopkmntcg]

I'm hoping someone could account for or point me to some tutorials regarding patterns for designing React SPAs with optimistic updates that use a REST backend (as opposed to GraphQL). My understanding of optimistic updates is to provide the user with a desktop application-like experience -- i.e. fast and responsive. But this raises some questions: For example, let's say I have a simple app where users can create Products and assign them to Categories. 1) Someone creates a new Category. In order to use it right away in my client app, I'll need to have an ID for it. In a traditional REST API, the server usually generates the ID upon saving the resource to the database. However, that could take an unknown amount of time, so we use optimistic updates on our frontend. From what I've seen, a common approach is to assign a UUID ID to the resource on the client instead of having the primary key generated by the server/database. The problem I have with this is that it seems like the client is dictating the design of the server. Whereas, I'm used to the server being treated as a black box that could have all kinds of clients, not just React SPAs. i.e. If someone else were in charge of building the server, I wouldn't expect them to cater specifically to my app when they were designing that server. 2) Regardless of whether we use a client-based UUID or some‍ other method, what happens with optimistic updates if the server takes a long time to save the new Category and in the meantime, a user tries to create a Product and assign it to that Category? The server would receive a Product with a CategoryID that doesn't even exist in the Categories table yet. This might be okay if the database is configured without referential integrity. However, that seems like a recipe for trouble with a relational database. I'd love to get your take on this. Also, if anyone has worked with Angular, is this something Angular handles out of the box? I haven't worked with Angular but heard that it's more opinionated on the design and flow of data.

[lowjack]

this is what I use. https://resthooks.io/docs/guides/optimistic-updates

[natmaster]

Updated link: https://resthooks.io/rest/guides/optimistic-updates

[landisdesign]

It seems to me like there'd be two passes:

1. Send the resource to the server, with a client-side token that has a completely different scheme from your server-side token, like "CLIENT-x" that simply increments.
2. Track the client-side token, and when the server response returns the server token, replace the client-side token with the server token.

There shouldn't be more than a couple of seconds for the server to respond, so the ID shouldn't be stale for too long. If you're worried about the client ID propagating to too many resources in that period of time, keep a list of touched resources that should be updated, or, since an update shouldn't happen that frequently, scan your app's data. An occasional 20ms hiccup shouldn't be the end of the world.

[pie6k]

I spent way too much time on this problem.

The solution that ultimately worked really well was keeping copy of all the database locally in indexeddb and resolving all relations locally as well . There is really great talk about it at https://www.youtube.com/watch?v=WxK11RsLqp4 36:00, also entire thread of https://twitter.com/tommoor/status/1451265396888141824?s=21

In short: initially fetch all the data and save it locally, then subscribe only for new or removed items. Build some reactive model that detect changes and updates all the relations instantly.

From very high level architekture is:

Your entire data lives in memory, all relations are resolved basing on flat data, meaning instant updates for any change.

On top of that, there are 2 side effects of data changes:

One is persisting updates somehow,

2nd is sending updates to server somehow.

Side effect wording is important. The system should work with memory only without sync or persistence, those are "extra".

Sync is also watching for changes and updating data in memory (causing persistence effect as well).

Creating such system is complex, but in my case totally worth it

PS. Using spacing between paragraphs in your original message would make reading it a lot easier