Let's reason about client-server state management in web apps
I am developing an open-source web app DSL/framework and I would like to find the best abstraction for the client-server state management (SPA + API server, what we use Redux, MobX, Apollo and similar for).
The fact that it is a DSL gives me a lot of freedom to implement whatever might be the best solution, so I am trying to think about it from the ground up.
Below are my thoughts so far, to start the discussion - I would love to hear yours!
1. Where is complexity coming from?
The problem arised with SPAs because UI logic moved from the server to the client, while server remains the source of the data. Therefore, we are sending more data over the network, and we have to be smart about what we fetch, and we need to cache it -> so complexity happens there.
2. Solutions: Implicit vs explicit cache
Implicit (Apollo, react-query): focus on operations, cache is implementation detail. Explicit (Redux, MobX): focus on the cache which you have to explicitly model.
3. RPC + meta data as a core solution?
Insight #1 -> Before the SPAs, we were dealing with the data via just logic on the server -> function calls.
Insight #2 -> Implicit cache solutions are becoming more popular than explicit ones -> operations > cache ~> functions.
So, currently best solutions seem to be converging toward how it was in the past, before the problem ever arised. Can we abstract the client-server state management to again feel like just calling functions?
If so, some form of RPC might be the solution. However we can't just ignore additional complexity, but maybe we can solve that by adding some meta-data to our functions, and that is it? It sounds true to the core problem and relatively simple.
This is somewhat abstract, here is how I implemented this specifically in the DSL for now: https://wasp-lang.dev/docs/language/basic-elements#queries-and-actions-aka-operations .
This is it shortly, let me know how you see it!
No comments yet.