I haven't implemented this pattern (and I'm not convinced it is widespread or even exists in a cohesive form yet) but I've become quite bedazzled with the idea of "UI as pure function of state" a la React/Redux, but with state maintained in the backend database and transmitted to the client via websockets, instead of locally.

Assuming a real-time interactive application, the major components would look something like this:

- Backend service distributed geographically to facilitate low latency to clients, with a single writer node and many read replicas

- Backend data store is SQLite, and importantly runs as a process on the same VM as each of the service nodes, so that there is no need for any network roundtrip to query the database on a read operation

- Clients subscribe to the service and receive a single JSON object representing the UI state

- Database modifications trigger a websocket notification to all subscribed clients with the respective diffs to the state object

- On the client side, a library like React (my choice, but of course there are others) watches the state object and renders the UI accordingly. Client writes are routed to the writer node (Traditional caveats about RYOW apply), UI updates are optimistically applied

- Pure client side state (modals, etc.) is handled solely via the frontend

It's tangential to the architecture, but this obviously would be well suited for something like fly.io. I'm sure many of the Phoenix people are nodding their heads as this architecture bears a lot of resemblance to LiveView, which I am also interested in for its own merits.

I see this as essentially a marriage between React/Redux and LiveView; it essentially comes down to having a globally replicated SQLite DB serve as your Redux store, but "over the wire" and it's colocated with your API layer.

What's the motivation? For me, React/Redux with Redux Toolkit is pure bliss for any sort of UI development. Throw in Tailwindcss and you're really rockin'. The problems arise from the impedance mismatch between maintaining application state locally in a Redux store when the true source of truth is your DB, and all the network traffic/caching considerations/api logic that needs to come with that. (You've actually got a distributed system on your hands)

If you can keep the client focused on the UI, then the complexity mostly lives in the API service layer where writes are replicated to all the VMs. It wouldn't work for every style of app, but with a service like fly.io behind you this tradeoff starts to look very attractive.

(Aside: I think this is why a lot of HN'ers are so excited about fly.io. If I can distribute my application and achieve super low latency relatively simply that is a step-change and opens up so many avenues of experimentation for development)

If the application were a more traditional read-heavy website and didn't need real-time updates, I might rip out the websocket layer and replace it with something like Remix, which I see as sort of a "rendering layer" that sits between the client and the backend for React apps.

Anyway, it's an exciting time to be a web dev. I would be curious to hear if anyone else has pondered a setup like this.

EDIT: Formatting