Single-page application only on websocket, who did it?

Question

Angular

There is a stage of selection of technologies for the implementation of the service, which implies the need to implement RealTime.
Front-end is planned to be written in AngularJS.
For the backend, we choose between two options:
1) AngularJS receives data via API. The API server (let's call it that) is written in python (django) for realtime, we raise NodeJS with socket.io
2) Crazy, but interesting and funny idea to implement the entire backend on NodeJS exclusively via websocket (socket.io). No Http API requests, only websocket(socket.io).
If everything is pretty obvious with 1, then there is a lot of uncertainty about the second.
So the question is, did someone implement the backend according to the 2nd scheme and what pitfalls did they encounter or is it completely nonsense?
PS I am writing a question because the second idea is interesting, everything is wonderful and beautiful in my head, but something is alarming, so I decided to consult it so to speak.

Answer 1

Absolutely normal idea. According to scheme No. 2, I have an entire window factory automated. socket.io was used. The architecture of the application, of course, differs from the standard SPA on AJAX requests, but on the other hand, RealTime synchronization of model states on all clients and the speed of data exchange (no connection losses) are very pleasing. It all works reliably.
UPD Here I wrote about it in more detail: NodeJS for project development

Answer 2

To begin with, you are now simply choosing a transport, either HTTP or WebSockets. From a conceptual point of view, there is not much difference. In terms of performance, everything depends on the chosen architecture.
In fact, websockets will work more productively (if we do not take HTTP2 into account), but you will have to implement request / response multiplexing, somehow write your own protocol on top and in a word a bunch of crap. Despite the fact that there are not so many performance benefits compared to the good old HTTP + Keep Alive.
For realtime - yes, of course, websockets is the best solution, but using it entirely as a transport is a dubious exercise. On the other hand, there are ready-made transport implementations on websockets where the problems that I listed have already been solved (perhaps not completely, but more).
ps I tried to do everything on websockets but without multiplexing, I didn’t have to resolve concurrent or parallel requests, everything went through a queue and the tasks were very simple. And why websockets was chosen - because it was used all the same, and it was too lazy to write API for one method.

Answer 3

We use Autobahn . It is too early to talk about any results, but overall the impression is very good.