How can I use socket io to send events to particular users who can overlap in rooms?

Question

I have an app in which users can check in to different places (like facebook's check-in feature). The check-in can either be public (in which case any app user in a range of x miles can see that check-in) or private (only that user's friends can see it).

I need to implement socket in the app so that whenever a user checks in or checks out, the map view of others (based on the settings, it could be public or private) is updated automatically.

What is the best strategy to handle this situation? I was thinking that a new room would be created for each checked-in user and his friends would be joined in. Or, I'd save the socketId of each logged-in user and emit an event to a subset of users when a check-in occurs (like a notification)

Answer 1

Let me review what I think you said is the flow:

1. UserA checks in at location A (let's say it's a public checkin)
2. Your server decides what other users it needs to notify of that checkin (based on proximity of location) and sends them a socket.io notification that lists the user and their new checked-in location.
3. When a client receives that notification, it updates the local map to show the new checked-in user and then (probably) alerts the local user that there's someone new nearby on their device.
4. When someone checks out from a location, you repeat the check-in process, but this time the event notifies them that the user is checking out and the client can remove them from their map.

The logic would be the same whether it was a public or private checkin/checkout. The only difference with the private checkin would be that you only analyze friend's locations for deciding who to notify rather than analyzing everyone.

---

So, if that's the overall flow, it seems that you just generically need the ability to figure out who is in the vicinity (within a certain distance) of a check-in/check-out location so you can notify them of a check-in or check-out event.

So, for step 2, you need to have previously stored the geographic location of all users that want to participate in this flow. You then need to be able to efficiently run through that entire list and figure out who is potentially within the target distance from the new check-in. While, you can calculate the absolute distance for every user, it is probably more efficient to first just check if the latitude or longitude difference is greater than some threshold because that will mean that the more involved math is not necessary to rule them out. This would leave you with only a subset of users to do the full match on to see if they were close enough. If you keep your list of users sorted by something like longitude value, then it would be even faster to find a subset to compare actual distance for.

Once you've found a set of users that are within a target distance, you send that set of users the socket.io notification announcing the new check-in. When those clients receive that message, they update their maps accordingly and do any user notification. You could save this set of users that you notified in a socket.io room, but I don't think that's really necessary (see steps below).

For step 4, a user checks out of a location. You can basically just repeat the process for step 2. Find out who is still nearby and send them a check-out message and they will update their maps accordingly. If you had saved all the users in a room, you could just broadcast this checkout to the room, but that creates some issues when users have moved since the check-in notification (see below) and it seems you can just use the same logic you previously used for step 2 to calculate the users to notify for step 4.

Users Moving While Others are Checked In

If UserB (who received a notification of UserA's checkin) decides to move before UserA checks out, you will need to both update the server with UserB's new location and have UserB update their own map. When, they update their map, they can remove any checkins from the map that are now too far from their new location (they save that information locally and just see who is now too far away). When they notify the server of their new location, the server then repeats Step 2 for their new location and notifies them of any users who are now close enough to them based on their new location.

If you used the room to store the original list of users for UserA's checkin, then you will have to update that room constantly every time someone in that room changes their location. Since there are potentially a lot of rooms to update every time someone moves, that seems like a lot of maintenance computation every time someone moves when you can instead, just recalculate who is close by whenever someone moves and you already need to make that calculate efficient anyway because it will be used a lot.

So, anyway, those are my thoughts. Hope it was helpful.