3 ms·
I disagree. I am currently all in for Websocket in web apps. HTTP is only used for static resources and scripts loading. In all webapps, there are buttons. In
by atemerev 11y ago
I disagree. I am currently all in for Websocket in web apps. HTTP is only used for static resources and scripts loading.
In all webapps, there are buttons. In some cases, clicking a button requires an action on the server, and therefore a roundtrip. If Websocket connection is established (you don't need more than one for everything), there is no overhead. With HTTP, you need to build a request every time.
Websocket plays nice with modern reactive streaming architectures. You send stream of events, you receive stream of updates. Everything is transparent and immutable and asynchronous.
If there is a connection loss, you are immediately notified and can move your app to offline mode. This is problematic with HTTP.
Websocket enable web apps comparable with native apps. HTTP apps will always feel less responsive to user actions.
- rahimnathwani 11y agoWould you mind sharing details of your preferred stack(s)?
- atemerev 11y agoReact or Riot.js on the frontend, Scala/Akka on the backend, Sockoweb as the dedicated WS server.
- gkfasdfasdf 11y agoI'm just curious, why did you use sockoweb instead of spray.io ? We have similar needs for a webserver that supports websockets and akka - spray.io seems like it would fit the bill.
- atemerev 11y agoA little too overengineered for my taste. I tried akka-http which is essentially Spray 2.0 and succeeded, but with twice the amount of code that I had with Sockoweb.