Two jobs, one application
Smocket replaces a separate Node.js mock server in focused frontend development and application tests. It does not replace the production backend.
Run a separate mock server process
Build backend-like events with the Socket.IO server package. The mock needs its own process, port, lifecycle, and browser network connection.
Use when the network connection should remain part of the local setup.Run mock server behavior in memory
Run the same handlers in memory for server-driven UI, rooms, broadcasts, acknowledgements, and multi-client application tests.
Use for focused development and application tests.Where Smocket runs
Choose a context to see who hosts the server and how clients connect.
Application tests in Node.js
Create a Smocket server inside the test, connect multiple clients, and assert the application event flow without opening a port.
- Host
- Vitest or another Node.js test runner
- Connection
- In-memory client and server
- Use it for
- Best for repeatable tests of rooms, broadcasts, acknowledgements, and server-driven state.
One application, two bootstraps
The drawing game registers one application function. Only the code that creates and connects the server changes.
Register the drawing-game event flow once
export function registerDrawingGameApplication(io: GameServer) {
const state = new DrawingGameState();
io.on('connection', (socket) => {
const actions: GameActions = {
join(current, room) {
return state.join(current, room);
},
stroke(current, segment) {
return state.rememberStroke(current, segment);
},
// Chat, guess, and disconnect use the same state.
};
registerGameHandler(io, socket, actions);
});
}Join, stroke, chat, guess, room state, and disconnect rules live behind this boundary.
Attach the application to the Node HTTP server
const io = new SocketIoServer(httpServer);
registerDrawingGameApplication(io, {
countdownMs,
});The Node.js mock owns a separate process, port, and network connection.
Attach the application to a SharedWorker
const io = new Server(GAME_URL);
registerDrawingGameApplication(io, {
countdownMs,
});
workerScope.onconnect = ({ ports: [port] }) => {
if (port) attachSharedWorker(io, port);
};The demo uses this browser runtime so three tabs can share one in-memory server.
A three-tab drawing round
Follow the same selected workflow through either runtime, then open the browser demo to try the SharedWorker path.
CONNECT ×3
Open three player tabs
- On screen
- Player A opens Players B and C. Each page receives a distinct socket ID.
- Event flow
- Three clients connect to the selected server runtime.
The demo uses the SharedWorker runtime shown above.
Observed behavior and boundaries
The table covers the drawing-game workflow, then separates what still belongs to the production backend.
| Selected behavior | Node.js Socket.IO mock server | Smocket |
|---|---|---|
| Three clients connect with distinct socket IDs | Observed | Observed |
| All clients join one room and receive shared state | Observed | Observed |
| A stroke reaches the other two clients, not its sender | Observed | Observed |
| Wrong and correct guesses return acknowledgements | Observed | Observed |
| A correct guess ends the round on all three clients | Observed | Observed |
| Closing a client removes it from the session | Observed | Observed |
Production network and integration behavior
- Transport, authentication, reconnection, and deployment
- Persistence and integration with the production backend
- Behavior outside Smocket’s documented API surface
One browser profile and origin
- Tabs share the same profile, origin, worker script URL, and worker name
- Worker restarts clear its in-memory sockets, rooms, and application state
- The automated browser run currently uses desktop Chromium