I find it difficult to decide between B) and C) because they differ mainly in where you make the requests and store the cached data; B: serverside, C: clientside.
The more ephemeral or user specific the data, the more appealing C is, but B has the benefit of never exposing API access tokens to the insecure browser env.
D) combines B) and C) by having the client manage the queue and retrying, but having the backend do the actual API requests. Its kind of best of both worlds; access tokens stay secure, and caching is done close to the user.
But also worst of both worlds since the clientside will now manage the cache and view so you can't send stale data with the initial page view and the serverside is still limited by it's HTTP request timeout.
@schizanon this is a great thread. There are downsides to many of these, but the more you keep it clientside (imo) the easier it is to experiment, and you don’t end up in awkward issues of middleware screwing up websockets.
I feel that the ideal solution is something that doesn't exist:
Z) Send the user an empty shell. in the same backend process that sent the shell, make all the API requests, retrying if necessary, and never timing out until all have finished. Send an event to the shell with the rest of the markup.
Basically the developer experience of A) but with the queue and recaching of B)/C) abstracted.
Like #ReactJS's Suspense without the ReactJS, and some kind of long-running multiresponse HTTP.
The problem is made worse if the data is ephemeral and frequently updated. #Caching becomes complicated, and ineffective whether that's done in the client or the server.
the user experience of both B) and C) can be improved by having something to send with the empty shell on the first request, even if it's old data. Prefetching can help, but cache invalidation could become a problem.
@schizanon Can you store the old data in IndexedDB so the next time the user opens the app you can show the old data while waiting for the API call to return?
C) send the client an empty shell. using #webWorkers have the client make the API requests retrying if necessary. Insert the results in a client side store and update the view.
B) send the user an empty shell. have the client establish a #webSocket connection. build a #backend#queue of #API calls to make. process the queue retrying as necessary. insert results into a backend #database. Update the client with the socket connection.
A) make the user wait for all the API calls to respond, if some fail retry them until they work. user sees nothing until all have successfully responded. shitty user experience, and the backend may timeout before all have finished.
Add comment