Proper usages of rooms/namespaces when making a News Feed with socket.io

Question

I am working on making a News Feed for a piece of software that will have data posted to different hierarchical levels within the software. For example, the software will support multiple organizations, each of which may have multiple teams, with multiple squads under each of those.

Top level users in the organization may see content from all of the content posted to anywhere in the organization (or any of its teams or squads). Medium level users should be able to see content posted to the entire organization, or content only within their own team (and its squads). The lowest level users should see content posted only to the entire organization, or their team, or their specific squad.

The database will also differential between 'posts', which can appear on a number of people's feeds and be commented on, and 'notifications' which are indicators for individual users that particular events happened, and must be dismissed by the user.

I should also note that at the moment, I am not interested in assigning different weights to posts and only making certain posts appear. I am fine with having everyone see every post relevant to them in reverse chronological order.

Now, I am planning on using socket.io to make this feed update live. From my understanding socket.io relies on namespaces and rooms to determine. My question is about how to leverage these features in order to make this feed function.

From a preliminary glance at it, I can see one of two ways of tackling the problem:

Option 1: Create socket.io namespaces (or perhaps rooms) for each node in the hierarchy of the organization (the organization itself, each team, each squad) and make each client join each of their relevant namespaces (top level users would join every namespace in the entire organization, bottom level users would only join the global organization namespace, their team namespace, and their squad namespace). The user facing feed would be an aggregate of all of the namespaces they are in.

The upside of this design is that since there are multiple users per namespace, even though I am writing new posts to the database, I can push posts directly from one client to the others in that namespace. This avoids having to do any database lookups for distributing posts to the other users that are already on the application.

Option 2: Create a socket.io namespace (or again, perhaps room) for each user. Then just have every client periodically poll the server for new posts that are relevant to them and should be displayed on their news feed. This option would effectively be an AJAX style solution without the overhead of actual AJAX calls to the PHP backend that this application is written in.

A sort of variation of this second option may be to still make a namespace for each user, but then when new content is posted, have the posts be pushed directly to other user namespaces. I am not sure if/how this would be possible.

I would appreciate it if anyone could give any advice on how to proceed.

Answer 1

Now that it has been nearly 3 years, and the software in question has been in production with hundreds of thousands of users this entire time, I am going to answer my own question.

I went with option 2, where each user joins a single unique room. The server does the work of iterating through the connected users and sending appropriate data to each user (using Redis PUB/SUB to manage the broadcasting of new events). In hindsight, this was definitely the right approach, as it allows for the siloing of each user's data. This is both conceptually easier to think about and easier to write code for, particularly when returning to the project to add features or making other adjustments to its business logic.