[k__]

> this isn't per-se a new paradigm

If you look how regular websites work, I think it is.

In my last project, people were kinda baffled, why the changes they made, didn't propagate to the other users instantly.

5 years ago everyone knew you had to refresh a page to see changes. Today everyone seems to expect these changes to be pushed to them.

It also was a fight to get this whole stuff working with React and Redux. So I think, if you want to build a good realtime site, you have to think about this stuff before choosing libraries, if you want to get good results.

For example, GraphQL has subscriptions that can be delivered via Websockets.

[jon-wood]

It surprises me getting it to work with React and Redux was a struggle, they seem like the perfect tools to handle a stream of state updates coming in realtime. You could practically dispatch client side events straight from the websocket stream to update local state.

[catshirt]

almost commented the same thing earlier. i was surprised how manual adding multiplayer support was for redux/react.

the solution was still pretty simple, for my app: 1. middleware that sends all actions to a server 2. websocket client that dispatches actions when they receive them. this works, but doesn't actually reconcile or keep data on the server which isn't suitable for most applications.

anyway yeah, i was surprised there was no robust or standard library...

[k__]

The problem was more the frequency of updates, than the integration.

I don't know, after working a year with Redux, it never grew onto me. Always felt clunky :\

[elcapitan]

Are there actually any patterns yet in how a stream of updates is being pushed to the frontend? In a way that would be like the frontend subscribing to an event queue through a websocket, I would imagine.