Is there any need/advantage of calling an api using the http client service when using websockets in angular?

Question

I am trying to learn how to use socket.io by building a simple chat app using the socket.io library and MEAN stack.

From looking at some open source projects(like this one) I have seen that the client, mainly when executing the chat logic, communicates with the server via websockets and not the http client service provided by angular.

Does this mean that when using web-sockets for real time updates there is no need to use http to communicate with the server?

Answer 1

Most assuredly not. It is not a matter of angular though, it's just choosing the right tool for the right thing.

Long story short:

• If it is a request/response model, then use http. Why?
  1. Because it's easier to handle. Proxies, dns and load balancers need no extra configuration to handle. Web Sockets do.
  2. You have already setup 1 so it's not a problem. How will you handle caching, routing, gziping, SEO and all the out of the box stuff the http protocol and rest-apis handle? Everything you build, all communications will need their own security consideration, design patterns etc.
  3. How will you handle the stateful nature of web sockets? They are currently supporting only vertical scaling, whereas rest apis scale both horizontally and vertically.

If you really need a full duplex communication (there is server push only without sockets), then you should limit web socket usage to the cases where you really need it.

Even in this case, go through a framework like signalR. All modern browsers support websockets but a lot of users still don't have browsers that do support them. SignalR falls back to long polling in those cases. If you use it on all cases, imagine what would happen if you use such a browser and you apply long polling for each request.

I could go on, but I think you get the meaning.