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.
I'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.
A 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.
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.