PartyPilot AI

Problem

Realtime apps fail when event payloads drift, validation is inconsistent, and client state becomes the “source of truth.” This needed a contract-first model and server-authoritative state.

Solution

• • Created shared contracts: types + Zod schemas used on both server and client.
• • Validated events at boundaries to prevent malformed payloads from breaking rooms.
• • Kept the server authoritative for game state transitions.

Architecture

pnpm workspace (monorepo)
  ├─ apps/web            (UI)
  ├─ apps/server         (realtime + state)
  └─ packages/shared     (types + Zod schemas)

Event flow:
client -> emit(event) -> server validates (Zod)
server -> updates state -> broadcasts snapshot/event

The key is “shared contracts” so server + client can’t drift.

Hard parts (senior signal)

• • Contract-first events: one source of truth for payload shapes.
• • Validation at boundaries: reject invalid events early to keep rooms stable.
• • Server-authoritative state: clients render state; server owns transitions.

Key features

• • Room creation + join flow
• • Realtime updates (state snapshot + event-based)
• • Shared schema package (types + Zod)
• • Predictable game loop boundaries

Demo script (Loom-ready)

1. Show monorepo structure and shared package.
2. Start server + web app, create a room.
3. Join from a second browser window and trigger actions.
4. Show server logs validating payloads (Zod).
5. Explain server-authoritative updates and state snapshots.