irt.io vs building it yourself
Socket.IO adds rooms, broadcast and reconnection on top of a WebSocket. It does not decide what you send or who is allowed to say it. Shared state, authority, serialization, interpolation, prediction and the server itself are yours.
The structural difference is the unit of work. With a socket you design and maintain a protocol. With irtio you declare a schema, and the protocol is derived from it.
When building it yourself is the better choice
- Your protocol is small and stable. A chat, a presence list, a live cursor feed or a notification stream is a hundred lines of Socket.IO. Adopting a platform for it is the larger change.
- You already run a backend. If the game state belongs next to your users, your billing and your database, keeping it in your own process is simpler than splitting it.
- You need clients irtio does not have. irtio clients are JavaScript and TypeScript in a browser. A native app, a game engine, a device or another service talks to your socket fine.
- The game must not depend on anyone else. Self-hosting is a requirement for some projects, and a socket server you own answers it.
When irt.io is the better choice
- The moment state has to agree. Broadcasting a message is easy. Keeping every client’s copy of the world consistent through packet loss, reconnects, late joins and a player who tabs away is the part that takes months.
- You would otherwise write the same four things. A delta encoder, a resync on reconnect, interpolation between updates, and a rule about who may change what. All four are the product here.
- The game is about movement. A room can step a Rapier or matter2d world at a fixed rate, and clients can predict the bodies they steer, so input is instant and the server still decides.
- You do not want to operate it. No process to keep alive, no scaling plan, no idle machine. Rooms sleep when nobody is in them and wake with their state intact.
Model comparison
| Socket.IO or raw WebSockets | irt.io | |
|---|---|---|
| Authority | Whatever your handlers enforce | Server, per collection |
| Who operates the server | You | irt.io |
| State model | Messages you design and encode | Schema of collections, synced as binary deltas |
| Prediction | You write it | Built in, one option on joinRoom |
| Physics | You write it, and you sync it | Rapier or matter2d, stepped in the room |
| Voice | A separate WebRTC stack | joinVoice(room) |
| Testing | Your own harness | In-process rooms with real clients, plus load runs |
| Idle rooms | Your process runs whether or not anyone is connected | Rooms hibernate and wake with state intact |
| Language | Anything with a socket library | TypeScript on both sides |
What porting looks like
Most of a socket codebase is deleted rather than translated. Migrating from Socket.IO walks through it in order. The shape is this.
First, find the object your server keeps per room. That object is your schema. Each map of connected players becomes an entity collection, each match or board becomes a singleton, and each loose field becomes a typed field with a fixed width.
Second, sort your events into two piles. Events where a client reports something about itself, a position or an input, become writes to an instance that client owns, with a validator on the server if a lie would matter. Events where a client asks the server to decide something become typed RPCs. Anything the server was broadcasting outward disappears entirely, because state changes reach clients on their own.
Third, delete the plumbing. The JSON encode and decode on both sides, the fan-out loops, the resync after a reconnect, the per-message version checks, and the code that reconstructs a newcomer’s view are all handled by the sync layer.
If you would rather keep your own wire format for now, a relay room is the halfway house. joinRelay() gives you room codes, presence and a raw message channel, with no schema and nothing
deployed. It is the smallest possible replacement for the socket server, and you can move to a
schema later without changing hosts.
Next steps
- Migrating from Socket.IO for the step by step version.
- Getting started to have a room running in a few minutes.
- The mental model for rooms, owners and the ladder from relay to full authority.
- Server authority and validation for validators and the tick loop.
- Retrofitting an existing game for adding a room to a game you already have.
This page describes each product’s model as it stood at the page’s last review. If something here is wrong or out of date, write to hello@irt.io and it gets fixed.