By default, each PartyKit project defines one party called main:
In addition to the main party, each project can define any number of additional parties using the parties configuration key in its partykit.json:
This is useful for:
Splitting unrelated functionality into different servers while deploying them together
Composing larger systems from multiple parties that communicate with each other
Accessing parties via HTTP or WebSocket
Each party is exposed at /parties/:party/:room-id, where the party path segment is the name of the party defined in partykit.json.
To connect to a party using PartySocket, specify the party name in the party argument:
Composing with multiple parties
Composing larger applications from multiple parties can be very useful when you want to manage information at different levels of granularity.
Accessing parties from other parties
All parties of the project are exposed on the Party object, accessible using the name defined in partykit.json.
Let’s say you’ve created a "user" party to store user and session state on a per-user basis, for example user preferences, e-commerce shopping cart, or similar. Each room (an instance of the party) is distinguishable by its id.
You can communicate with any room:
Example: Tracking connections across rooms
Let’s now look at a more fleshed-out example.
Let’s say you want to track of all room instances, and see how many active connections there are to each room.
You can define a connections party that keeps track of the number of active connections when it receives an update via an HTTP POST request:
Any other party can notify the connections party of connection/disconnection events by calling fetch: