5 ms·

More complex realtime applications can benefit from higher level concepts like data-sync (observable objects that share state between clients), e.g. http://deep

More complex realtime applications can benefit from higher level concepts like data-sync (observable objects that share state between clients), e.g. http://deepstream.io/ http://deepstream.io/ or https://www.firebase.com/ https://www.firebase.com/ or more complex routing strategies, e.g. AMQP exchanges. A great example of the impact of this kind of standardized protocol / architecture on top of a low level protocol would be REST on top of HTTP

fenesiistvan 11y ago
Ok, but then why the focus on the "websocket" which is just a simple protocol over TCP. Why not an "universal" app server which can handle also other transport layers. We already have these kind of frameworks (and "websocket" is just a single line on their endless feature list) Edit: anyway, i see where this module would fit, i was just curious why we need to use for everything a foreign component and create more dependencies for our projects instead of developing in-house such trivial modules
- neomantra 11y ago
  The specification says the WebSocket is the default transport; some implementations also support Unix Sockets and Unix Pipes. I have my own in-house WebSocket (raw, not WAMP.ws) application server and a very thin client-side API wrapper around raw WebSockets; it performs PubSub and some RPC. It's not rocket science but it's also not trivial. I might consider migrating that custom subprotocol to this framework. It looks like they have thought carefully about the general issues with PubSub/RPC and it will be easier to scale my use (as in expanding my RPC APIs, not in terms of # of clients). I can focus on my data and APIs, not on the substrate. Hopefully an ecosystem of designers/implementors/users emerges that make this thing awesome. Of course, I've thought that about other libraries and frameworks and it went nowhere, so we'll see.

fenesiistvan 11y ago

Ok, but then why the focus on the "websocket" which is just a simple protocol over TCP. Why not an "universal" app server which can handle also other transport layers. We already have these kind of frameworks (and "websocket" is just a single line on their endless feature list) Edit: anyway, i see where this module would fit, i was just curious why we need to use for everything a foreign component and create more dependencies for our projects instead of developing in-house such trivial modules

neomantra 11y ago
The specification says the WebSocket is the default transport; some implementations also support Unix Sockets and Unix Pipes. I have my own in-house WebSocket (raw, not WAMP.ws) application server and a very thin client-side API wrapper around raw WebSockets; it performs PubSub and some RPC. It's not rocket science but it's also not trivial. I might consider migrating that custom subprotocol to this framework. It looks like they have thought carefully about the general issues with PubSub/RPC and it will be easier to scale my use (as in expanding my RPC APIs, not in terms of # of clients). I can focus on my data and APIs, not on the substrate. Hopefully an ecosystem of designers/implementors/users emerges that make this thing awesome. Of course, I've thought that about other libraries and frameworks and it went nowhere, so we'll see.