What could be the drawbacks of replacing API calls with WebSockets?

Question

So I am planning on building a Single Page Application. In that application, there will be a lot of API calls, and very frequent from what we expect.

So we were thinking of foregoing API calls and replacing it with WebSockets totally. So how we're planning to make this work is as follows:

We designate a special code(or socket message type) for each resouce the client can request.
Client connects to the server via a websocket.
For each resource/data the client wants, it send a message to the server with the predefined code.
Server processes the request and sends the response back to the client.
Client and server keep the connection open, and any future requests are communicated over the same socket.

We expect to reduce overhead and latency with this approach, but is that a right assumption? Also, what could be the pitfalls of using this mechanism?

In our scenario we'd lose all kinda of exception handling and vendor error reporting provided by the specific API's. I don't know if that applies to you specifically. Our solution a similar problem was to move to Event Driven Design and queue up our API calls for a daemon to handle. — pcgben, Feb 07 '18 at 04:04
But you can't queue up all the calls you have if the client expects a response back ASAP. But logging and other long running stuff queueing is the way to go I agree. — Ayush Gupta, Feb 07 '18 at 04:06
you may want to consider the Actor model if you go down this path — Keith Nicholas, Feb 07 '18 at 04:07
@AyushGupta If your API endpoint allows concurrent connections, you can use a Daemon to fire them off as they come in. There are some cases where we are able to do this and others where the end points won't allow it, in which case we've been able to bundle a few together into the payload. There are a lot of variables to consider. — pcgben, Feb 07 '18 at 04:12
Possible duplicate of [Websocket vs REST when sending data to server](https://stackoverflow.com/questions/45460734/websocket-vs-rest-when-sending-data-to-server) — jfriend00, Feb 07 '18 at 05:50
Also relevant: [Websocket vs. REST for real-time data](https://stackoverflow.com/questions/28613399/websocket-vs-rest-api-for-real-time-data/28618369#28618369) and [Why use websocket over http?](https://stackoverflow.com/questions/44898882/why-to-use-websocket-and-what-is-the-advantage-of-using-it/44899221#44899221) and [What are the pitfalls of using webSocket over REST](https://stackoverflow.com/questions/29925955/what-are-the-pitfalls-of-using-websockets-in-place-of-restful-http). — jfriend00, Feb 07 '18 at 05:51
But I also think this question is too broad, and in the end asking for opinions. — GhostCat, Feb 07 '18 at 08:56
Since browsers already keep HTTP connections open and reuse them automatically, I don't see anything in your plan that will reduce overhead and latency. I do see a lot of work and a lot of complicated connection management code, however. — Matt Timmermans, Feb 07 '18 at 14:04

score 1 · Accepted Answer · answered Feb 07 '18 at 06:09

WebSockets are preferable if you are writing a messaging app or a game. If your app hits the db frequently you can consider Server Sent Events

WebSockets have a bidirectional communication between a client & a server. You may not necessarily require websockets.

WebSockets may look like HTTP but only at the start. It isn't HTTP. There might be possible side effects that haven't been considered in the design of the protocol. They keep the connection open on the server for the duration of the time the user is interacting with the page. This will increase the demand on the server, and means that you will always have to scale OUT rather than UP. If don't have a msging app or a game, I believe WebSockets is a less economical choice.

What could be the drawbacks of replacing API calls with WebSockets?

1 Answers1