I think websockets as you're using it is a stand-in for realtime-first development.
This territory is well explored -- services like firebase/parse are a testament to many usecases.
IMO, this isn't per-se a new paradigm in the likes of offline-first, which is advocating for local application cache/data synced with a remote store, this offering the benefit of offline apps, with the sync/realtime benefits of network connected apps.
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.
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.
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...
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.
I think that realtime-first is correct. Websockets is just a protocol that support bidirectional communication. Plain old HTTP requests paired with Server Sent Events over H TTP/2 are technically bidirectional communication over the same connection too.
Google is also working on GRPC for the browser. Tomorrow it could be a completely different protocol, but it's all in the pursuit of making the app more realtime.
If you're interested in Realtime-First development, Meteor has been doing it since 2013 and is very production-ready at this point: https://www.meteor.com/
This territory is well explored -- services like firebase/parse are a testament to many usecases.
IMO, this isn't per-se a new paradigm in the likes of offline-first, which is advocating for local application cache/data synced with a remote store, this offering the benefit of offline apps, with the sync/realtime benefits of network connected apps.