3

I'm currently trying to make a chat app. I'm wondering how I should design my server-side. I plan on having a few schemas - messages, users, groups. I have a few ideas on how to do the design:

  1. No API and only websocket communication. This would be ideal but it won't be easy to do stuff like edit things from the DB.
  2. I only use the websocket to tell the client-side that there's been an update and tell it the URL to get the new data. This would be easier but I'm not sure if it's a viable idea.

I'm quite new to websockets and would like to hear your suggestions. If you have a better design for the back-end please tell me. In case you need to know - I plan on using JavaScript for the server.

ProGamer2711
  • 451
  • 1
  • 5
  • 18

2 Answers2

2

In my view, it is better to use both. They have different goals. WebSocket can be used for:

  • to send server-push of data.
  • to send small pieces of data from client to server and you do it very often

REST can be used:

  • when you use server-side frameworks
  • when you do not want to open your websocket all the time. So your server will have more scalability
  • you do want to avoid inactive long-connected periods

UPDATE

WebSockets keep your connection alive. So you can receive your messages without delay. But the price for this is scalability of server. REST can be used to upload images.

StepUp
  • 36,391
  • 15
  • 88
  • 148
  • Ok but what do you think would be best given the idea of a chat application (messages being sent quite frequently). I also have no idea about scaling and how to open the websocket only when I need to. – ProGamer2711 Oct 31 '22 at 18:16
  • 1
    @ProGamer2711 It has many pros and cons. Please, see my updated answer. In additon, you can read more about [Is it ok to use HTTP REST API for Chat application?](https://stackoverflow.com/questions/29217209/is-it-ok-to-use-http-rest-api-for-chat-application) – StepUp Oct 31 '22 at 18:35
  • 1
    Thank you. I'll read it now. – ProGamer2711 Oct 31 '22 at 19:53
  • 1
    No problem. Thank you for the help. I will not mark it as the best answer yet since I'm still not too sure what I should do. Soon I will decide what to do but until then I'm still open to other answers. If nothing comes up I'll choose your answer as the best. – ProGamer2711 Nov 01 '22 at 10:40
  • @ProGamer2711 I would use sockets for communication between users. If you have a chance to use many ports for your server, then it is way to go. And you can use REST for uploading images – StepUp Nov 01 '22 at 12:42
  • I am not asking about if I should use websockets. I'm asking what the best way to use them would be - along with an API, using the socket to tell the client when he should ask the API or socket all the way (except for images) – ProGamer2711 Nov 01 '22 at 14:53
1

I think this question boils down to load balancing. HTTP is good if a few secs delay does not matter and messages are relative big and we are talking about REQ-REP communication. Websockets is good for close to real time communication, many small messages are fine with it and it supports PUSH-PULL type communication.

PUSH-PULL e.g. push notifications can be emulated by HTTP with polling, but always rebuilding the connection makes it too costly. Websockets can do push notifications, but it might be more cost effective to use an external service e.g. Google notifications service for it, because it can be costly to maintain that many connections to users who are not active at all for many hours and do only the real time part with your own websockets server.

HTTP supports caching and stateless communication which makes it highly scalable compared to websockets, so if something is reusable e.g. scrolling back to earlier messages, then better to use a caching mechanism e.g. in-memory cache by storing e.g. the last 25 messages in memory or HTTP cache by storing several messages in the file system. Though it depends on the client, e.g. a mobile client might be able to have its own filesystem cache without HTTP. Another thought, that event for an in-browser desktop client can store some data in the filesystem and messages or not that long, so even there it is possible to cache using localstorage and sessionstorage and use HTTP only for bigger files like images.

So I think the real-time chatting part must go with websockets, because it requires low latency. Loading previous messages can be done with REST and a pagination solution. Push notifications can be done with websockets too, but maybe better to use a different server, so it won't affect the performance of the real-time chatting and it can have somewhat higher latency, e.g. even a min or so. The actual implementation depends on the expectations regarding to latency, scalability, etc. and the supported platforms e.g. browser, Android, iOS, etc.

inf3rno
  • 24,976
  • 11
  • 115
  • 197