Reactive GraphQL Architecture
As part of designing proposed architecture solutions for some Meta web apps, I wrote a GitHub issue outlining a vision for an application architecture which leverages the GraphQL language to model rich, reactive, client state as fields and types stitched into a GraphQL graph which can (optionally) also expose server state.
You can read the full write up here: https://github.com/facebook/relay/issues/4687
The architecture allows a sophisticated GraphQL client (Relay?) to coordinate:
Fetching of server data
Reading of and (subtraction to) client data sources
Reactive (re)computation of data derived from the above
Efficient updates of UI components derived from 1,2,3
It does this while presenting a unified, and tool-supported interface to product code, GraphQL, providing a structured way to define your data layer, and also offering a path to moving heavy client star off the main thread.
I think this is a very interesting architecture to explore for apps with a large contributor bases, heavy client state, and a need to use a hybrid of client and server state.
Local-First
The Local-First architecture movement is hopeful that many apps will eventually be able to be built against a fully local database, with the server reduced to a distributed systems synchronization problem. I hope they’re right! But, for the time being, I remain convinced that even if their vision is wildly successful, most real apps will continue to need to meaningfully incorporate traditional request/response server data. If that proves to be the case, an architecture like this may prove quite useful.