Rooms

Rooms provide logical namespaces for organizing topics within your application.

What are Rooms?

Rooms are containers that group related topics together. They help organize your messaging structure and provide isolation between different contexts (e.g., different game lobbies, chat channels, or user spaces).

import { NoLag } from '@nolag/js-sdk'

const client = NoLag('your_access_token')
await client.connect()

// Set up app and room
const room = client.setApp('my-app').setRoom('game-lobby')

// Subscribe to topics within this room
room.subscribe('chat')
room.subscribe('player-updates')

// Messages are scoped to this room
room.emit('chat', { text: 'Hello lobby!' })

Room Types

Static Rooms

Seeded from the app's blueprint when the app is created, and manageable in the dashboard. These rooms exist permanently (they can be disabled but not deleted) and are ideal for fixed channels like general, announcements, or support.

Dynamic Rooms

Created programmatically via the REST API for user-specific or session-specific namespaces. Dynamic rooms must be created server-side before clients can use them.

Step 1: Create Room via API

Room slugs are stored exactly as given (or derived from name by lowercasing and replacing runs of other characters with -). Pass a slug explicitly and use the value from the response when you connect.

import { NoLagApi } from '@nolag/js-sdk'

const api = new NoLagApi('your_api_key')

// Create a dynamic room - inherits topics from app config
const room = await api.rooms.create(appId, {
  name: `Game ${gameId}`,
  slug: `game-${gameId}`
})

console.log('Created room:', room.roomId, room.slug)

Step 2: Grant Access (optional)

A room with no grants is public to every actor in the project that can reach the app. To make it private, grant the actors that belong in it. The first grant is what closes the room, so grant everything that needs access, including your own backend services, in the same step. All three REST clients expose room grants; see Access Control for the full rules.

// Grant one player pub/sub on the room's topics
const grant = await api.rooms.grantActor(appId, room.roomId, {
  actorTokenId: playerActorId,
  permission: 'pubSub',
  topics: ['moves', 'chat']
})

// Inspect and revoke later
const grants = await api.rooms.listActors(appId, room.roomId)
await api.rooms.revokeActor(appId, room.roomId, grant.roomActorAccessId)

Step 3: Connect via WebSocket

Use the app slug the control plane returned when you created the app (it carries a random suffix, for example my-app-a3f9) and the room slug from Step 1:

// After room is created via API, connect to it via WebSocket
const gameRoom = client.setApp(APP_SLUG).setRoom(room.slug)
gameRoom.subscribe('moves')
gameRoom.subscribe('chat')

Actors only see the rooms that existed when they authenticated, plus rooms the broker re-checks with the control plane on a cache miss. If a client connected before the room was created and its subscribe still fails, reconnect it.

Public vs Private Rooms

By default, rooms are public, meaning any actor with access to the app can connect to them. The moment you attach one or more actors to a room, that room becomes private. Only the attached actors can access it.

This means access control is built into room assignment rather than requiring separate permission rules. A few examples:

• Notifications: attach a user to their own room, and only they receive their notifications
• Team chat: attach team members to a shared room, and outsiders can't join
• Device telemetry: attach a device and its owner to a room, isolating the data stream

Topic Inheritance

Every room inherits the topics defined on its parent app. When you create a chat app with messages and _typing topics, every room in that app, whether static or dynamic, automatically has both topics available. You configure topics once at the app level and they scale to thousands of rooms.

Topic Resolution

Topics within a room are namespaced automatically. When you subscribe to chat in room game-lobby of the app whose slug is my-app-a3f9, the full topic path is my-app-a3f9/game-lobby/chat. That three-part path is the only hierarchy: topic names themselves are single tokens with no /.

Use Cases

• Game lobbies - Each game session gets its own room
• Chat channels - Separate rooms for different conversations
• User spaces - Private rooms for user-specific notifications
• Multi-tenant apps - Isolate data between organizations

Next Steps

• Learn about Topics
• Set up Access Control