Implementing REST API + Socket.io with permission management and notifications

Issue

I'm currently trying to code a restful API in node.js/express doing some classical CRUD stuff. Alongside, I want to be able to notify (notification system) the clients of this API when a Create/Update/Delete event occured with the help with ws or socket.io for simplicity. In addition, I implemented a permission system (inspired by permissions for file systems) with inheritance for each object impacted by the API and each notification must deal the same permission and inform only the authorized users.

So to summarize: API REST using Node/express with a fine permission system in combination with socket.io for notification system.

The ideas and questions I have are the following:

• Is using REST/API in combination with web sockets a good idea ? Since I will need a permanent ws connection for the notification system and maybe a chat later, would it be better to code the API only using ws ?
• For managing permissions on the socket.io part, the idea is to create temporary room and add the current listeners with the suitable permissions (coming from DB) then remove the room once the notification is broadcasted. Is there other options for this ?
• In the same step, the notification will also be added into the database for the clients not connected to the client app when the event happenned. Once they will reconnect, they will see the notifications.
• Since the REST API is not depending on the notification system would it be a good idea to implement a fire and forget function to create the room and emit the notification but let the REST API to send the response on the other side ? Would it be pertinent to look on creating a new thread for this ? Since sending nofitications will not be really CPU heavy, I think it is a bad idea...

If you have any thoughts, good practises, examples or critics on this please don't hesitate to comment. Thanks.

Solution

Sounds like a cool project!

Is using REST/API in combination with web sockets a good idea ? Since I will need a permanent ws connection for the notification system and maybe a chat later, would it be better to code the API only using ws ?

REST endpoints are much easier to code and handle than websockets IMO, so I'd say that it makes sense to keep things simple where possible.

For managing permissions on the socket.io part, the idea is to create temporary room and add the current listeners with the suitable permissions (coming from DB) then remove the room once the notification is broadcasted. Is there other options for this ?

I think it could be simpler to just have one room per connected listener and push the message to each room instead, but that's just personal preference.

Since the REST API is not depending on the notification system would it be a good idea to implement a fire and forget function to create the room and emit the notification but let the REST API to send the response on the other side ? Would it be pertinent to look on creating a new thread for this ? Since sending nofitications will not be really CPU heavy, I think it is a bad idea...

This sounds an awful lot like premature optimization to a problem that you might not have. I'd suggest you first implement it the simple way, then start optimizing only if you encounter performance issues. Profiling is your friend.

That being said, frequently starting new threads is generally a bad idea, since the overhead of creating it is not neglegible. You can consider using a worker thread responsible for handling the notifications that permanently runs in the background and handles notifications from a queue. When a notification should be handled, it is instead written to the queue, so that the background thread can handle it. Many web frameworks also allow firing off background tasks that are run asynchronously.

If you need to scale to multiple processes/servers, this sounds a bit like a use-case for Redis, which provides data structures like Queues and publisher/subscriber systems that can be accessed across the network.

Answered By - georch