4 ms·

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 testa

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.

k__ 10y ago
> 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.
- elcapitan 10y ago
  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.
- jon-wood 10y ago
  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.
  - k__ 10y ago
    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 :\
  - catshirt 10y ago
    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...
caleblloyd 10y ago
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.
jasonl99 10y ago
Yes, you are completely right. It should have been titled "Realtime-first development with Websockets".
djmashko2 10y ago
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/ https://www.meteor.com/

k__ 10y ago

> 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.

elcapitan 10y ago
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.
jon-wood 10y ago
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.
- k__ 10y ago
  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 :\
- catshirt 10y ago
  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...

caleblloyd 10y ago

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.

jasonl99 10y ago

Yes, you are completely right. It should have been titled "Realtime-first development with Websockets".

djmashko2 10y ago

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/ https://www.meteor.com/