PHASE 4 — Topic 16: Broadcasting Messages to Everyone, or to Specific Users/Rooms

We've used several broadcasting patterns already across earlier posts. This post pulls everything together into one clear reference, and adds a few useful patterns we haven't covered yet.

The Complete Emit Cheatsheet

Here is every major way to send an event, all in one place:

    io.on("connection", (socket) => {
        // to this one client only
        socket.emit("event", data);
        // to everyone except this client
        socket.broadcast.emit("event", data);
        // to everyone, including this client
        io.emit("event", data);
        // to everyone in room1, except this client
        socket.to("room1").emit("event", data);
        // to everyone in room1, including this client
        io.to("room1").emit("event", data);
        // to everyone in room1 or room2, except this client
        socket.to(["room1", "room2"]).emit("event", data);
        // to everyone, except those in room1
        io.except("room1").emit("event", data);
        // to a specific client by socket id (private message)
        io.to(socketId).emit("event", data);
    });

to() and in() are exact aliases of each other, they behave identically. Most codebases just pick one and stick with it for consistency, to() tends to read more naturally.

A Warning Worth Remembering

You might expect socket.to(socket.id).emit(...) to work as a private message to yourself, but it does not. Every socket automatically has a room named after its own socket.id, and socket.to(...) explicitly excludes the sender. So socket.to(socket.id) targets that room while excluding the one socket in it, meaning nobody receives it. For sending an event only to yourself, always use plain socket.emit(...) instead.

Excluding a Room With .except()

Sometimes you want to reach almost everyone, except one specific group. .except() handles this cleanly:

    io.except("banned-users").emit("announcement", data);

You can also chain multiple .except() calls, or pass an array of rooms to exclude several at once:

    io.to(["room1", "room2"]).except("room3").emit("event", data);

Private Messaging Between Two Specific Clients

Combining what we know about rooms and socket IDs, a private one-to-one message between two connected users looks like this:

    socket.on("privateMessage", (targetSocketId: string, message: string) => {
        socket.to(targetSocketId).emit("privateMessage", {
            from: socket.id,
            message,
        });
    });

Since every socket has its own default room named after its ID, targeting targetSocketId here works exactly the same way as targeting any other room, it just happens to contain exactly one client.

Broadcasting Across Multiple Devices of the Same User

If the same user has your app open in two tabs, or on both their phone and laptop, they will have two separate socket connections, each with a different socket.id. If you want an event to reach every device belonging to one user, you need a way to group those specific sockets together, typically done by having each socket join a room named after the user's actual user ID (not the socket ID) upon connecting:

    socket.on("authenticate", (userId: string) => {
        socket.join(`user:${userId}`);
    });
    io.to(`user:${userId}`).emit("notification", data);

Now, regardless of how many tabs or devices that user has open, all of them receive the notification, since they all joined the same user:<id> room.

The compress Flag

By default, Socket.IO compresses data before sending it. For very small, frequent payloads, this compression overhead can occasionally cost more than it saves. You can disable it per emit if needed:

    socket.compress(false).emit("event", data);

This is a minor optimization, and rarely something you need to think about early on, but it's useful to know it exists.

The local Flag: A Multi-Server Consideration

Once your app scales to multiple server instances (which we'll cover properly in Phase 6, using the Redis Adapter), broadcasting normally reaches clients connected to any server in the cluster. If you specifically only want to reach clients connected to the current server process, you can use .local:

    io.local.emit("event", data);

For a single-server setup, which is what we are running throughout this course, .local behaves identically to a normal broadcast, since there is only one server anyway.

A Performance Tip Worth Following

One subtle but important best practice: avoid doing async work directly inside a broadcast call, since it delays the entire operation unnecessarily:

    // Avoid this
    io.to("room2").emit("details", await fetchDetails());
    // Prefer this instead
    const details = await fetchDetails();
    io.to("room2").emit("details", details);

Resolving your data first, then emitting, keeps the broadcast itself fast and synchronous, rather than blocking on an async call in the middle of it.

Applying This to Our Chat App

Looking back at our chat app from Topic 13, we used io.emit("newMessage", data), sending to everyone including the sender, to keep the server as a single source of truth. Now you can see exactly why that specific choice was made, and how it fits into this bigger picture of broadcasting options. As your app grows, for example, adding private messages or per-user notifications, you now have the full set of tools to choose the correct emit pattern for each situation.

Summary

• socket.emit, socket.broadcast.emit, io.emit, socket.to(room), and io.to(room) cover the majority of real-world broadcasting needs
• .except(room) excludes specific rooms from a broadcast, and can be chained or passed an array
• socket.to(socket.id) does not send to yourself, use plain socket.emit() for that
• Grouping a user's multiple devices into a shared room (e.g. user:<id>) lets you broadcast to all their sessions at once
• .compress(false) and .local are minor, situational tools, useful to know about but rarely needed early on
• Resolve async data before emitting, rather than awaiting inside the emit call itself

This completes Phase 4. In the next post, we begin Phase 5 by handling reconnection, offline users, and connection state recovery, the first step toward making our app production-ready.