I'm attempting to build a small app with node.js, express, and socket.io, which involves handling basic social relationships. There are multiple users, you can request to be friends with them, accept these requests, reject them, and unfriend users -- basically, a lot like Facebook. If user A is logged in, and user B requests a friendship with him, I want user A to be informed immediately about the friend request. This is where websockets (and the confusion) come in.
Would each user have three different socket connections, corresponding to the three data collections? (1) Friends, (2) Received Requests, (3) Sent Requests
Upon a user accepting a received request, the other user would need to be informed that his sent request has been accepted. Would this require triggering an event on the other user's socket? What if that socket doesn't exist because the user isn't online?
Apologies if there's confusion, but I'm having difficulty understanding how to conceptualize the relationship between sockets.
You would set up each socket as an object with that socket corresponding to a specific users data. if you're unfamiliar with objects and other structured data this is super important and you wont get very far without that.
You would have an object called users which would contain each users id in an array which would then hold each users information by id including arrays for friends, requests etc.
Because the data is being held on the server side, even if the socket is closed by the user on the client side the data has already been passed to a variable and saved on the server side.
Doing this entirely in node is going to take quite a bit of effort if you're unfamiliar, I would start by building the app with a mysql database first and then play around with holding the data within the app.
All this (including the previous answer) will become a whole lot clearer to you if you read up on the "publish/subscribe pattern" ("pubsub"). The essential aspects of this pattern are:
1) You have "people" ("talkers") who each have "something to say" that might be of interest to others.
2) You have "people" ("listeners") who each "want to listen" to some other "people" (though very rarely to just anybody; most of them are choosy about whom they listen to, if only to keep from being overwhelmed).
The publish/subscribe pattern describes how to "connect" talkers with listeners in such a way that the talkers aren't burdened with having to keep track of who their listeners are, and listeners aren't burdened with having to keep track of which talkers they decided to listen to (i.e. they don't have to "hear" everybody talking and try to filter the ruckus down to what interests them).
As MagicDev pointed out, this generally involves an object whose data portion keeps track of who's listening to which talker and whose methods allow a talker to say "I'm talking about this subject" ("publish") and a listener to say "I want to be notified when (list of talkers, or "anybody") talks about a certain subject (which could possibly be "any subject").
A "friend relationship" generally means that "person" A becomes a "talker" to "person" B as a "listener" and vice-versa. However, there's nothing in the pubsub pattern that mandates this kind of symmetry; a good implementation will let you use the same methods to establish "broadcasts" and "conversations".