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:
- 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.
- 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.
CodePudding user response：
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.
CodePudding user response：
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.