SPA: using websockets only. Why not?

Question

I am redesigning a web application which previously has been rendered server side to a Single Page Application and started to read about websockets . The web application will be using sockets to have new records and/or messages pushed to the client. I have been wondering why most pages which make use of sockets don't handle all their communication over the socket. Most of the times there is RESTful backend in addition to the websocket. Would it be a bad idea to have the client query for new resources over the socket? If so why - other than that a RESTful api might be easier to use with other devices?

I can imagine that using websockets would probably not be the best idea in case the network connection is kind of bad like on mobile devices, but that probably should work quite well with a reasonable connection to the web.

I found this related question, however it is from 2011 and seems a little outdated: websocket api to replace rest api?

Borchers

Thinking about the same in context of Distributed Event-Sourced CQRS + Redux app. Basically, to serve static content from whatever i want and exchange only pure actions/events over bidirectional websockets. Currently looking for arguments, why would i in addition need to maintain REST API if i have no external API consumers. – Selinaselinda

@Selinaselinda my very personal recommendation would be: If you reliably need to get data across the wire, use what the majority of the web uses. If you have good reasons to use something else (like WebSockets), it might make sense to do so. However, chances are good that you will also sign up for some edge cases, browser bugs and probably some workarounds to fix a few weird things. If your good reasons are still more important, go with it. As for me: I am currently taking some time to finally get rid of WebSockets as the main means of communication. – Borchers

Answer 1

Coming back to this question a few years later, I would like to point out a few aspects to illustrate that having all your communication through websockets does have its drawbacks:

• there is no common support for compression. You can easily configure your webserver to compress http requests and browsers have been known to happily accept compressed responses for years, however for web sockets it is still not that easy (even though the situation has improved)
• client frameworks often are build upon commonly used standards like rest. The further away you move from frameworks expectations, the less addons or features will be available.
• caching in the browser is not as easy. By now this goes a long way, reaching into the realm of offline availability and PWAs.
• when using technology, that is only used by a subset of users, it is more likely to find new bugs, or bugs might take longer to fix. And if it's not bugs, there might be an edge case somewhere around the corner. This isn't an issue per se - but something to be aware of. If one runs into those things, they often easily take up quite some time to fix or work around.

Borchers

Isn't a Sec-WebSocket-Extensions: deflate-frame meant to be for enabling compression? tools.ietf.org/html/rfc7692 – Selinaselinda

Yes, and probably my knowledge on that might be a bit outdated. I tried to find more information about current browser support, but wasn't able after a quick search. If you find good information about that, I would appreciate if you could also add it here. – Borchers

I will argue that setting up websocket server requires additional learning curve and websocket don't build-in reconnect (one of reasons to use socket.io) – Jesselyn

Yes, there are lots of reasons. I would simply put it: Don't do it unless there is a really good reason to do it. Or: Don't do it just because you can :) – Borchers

IMO the only reason to not use Websockets is that there is more inertial tooling and middleware around HTTP request/response, like caches, proxies, etc. But HTTP request/response sucks badly at live updating. The more live you want to make your app the more HTTP request/response, and frameworks built around that (Rails, Django, etc.), feel like medieval technology. – Arius

Answer 2

No, it won´t be a bad idea. Actually I work in an application that uses a WebSocket connection for all what is data interaction, the web server only handles requests for resources, views under different languages, dimensions .. etc..

The problem may be the lack of frameworks/tools based on a persistent connection. For many years most of frameworks, front and back end, have been designed and built around the request/response model. The approach shift may be no so easy to accept.

Hymie

Yep. Having a SPA talk to the backend over WebSocket only is a viable approach. You might be interested in wamp.ws, which provides the commonly used abstractions over WebSocket: remote procedure calls (RPC, similar to Ajax needs) plus publish & subscribe. In one WebSocket-based subprotocol. Disclosure: I am original author of WAMP. – Diamond

Right, I found WAMP and I think it is great, but we decided to design our own protocol. Our application works as a FSM, so there is no explicit subscribing for example, the server decides what is sending you depending on your state. – Hymie

What's an FSM? @Hymie – Motive

FSM is a commonly used acronym for Finite-state machine. I think I've heard FSM said more often than Finite-state machine. – Moreta