1.9 KiB
1.9 KiB
Proposed Direction
- Single core language: Go for all server runtime (gateway + lobby + game logic).
- Web/UI: TypeScript (Next.js or simple React/Vite) only.
- Goal: Keep binary protocol compatibility via a Gateway while the Core Monolith evolves.
———
Architecture (Monolith First)
[Game Client] ⇄ [Go Gateway] ⇄ [Go Core Monolith] ├─ Lobby module ├─ Matchmaking module ├─ Game loop module └─ Data access layer
- Gateway: speaks binary protocol; maps opcodes to internal RPC/handlers.
- Core Monolith: simple Go service with clear module boundaries; no network protocol details here.
- Data: Postgres + Redis (optional) behind a DAL.
———
Phase 0: Baseline Observability (immediate)
- Add request/session IDs at the lobby entrypoint.
- Add JSON logs (opcode, account, session, latency).
- Add packet capture/replay harness (proxy or gateway shim).
This sets up parity testing for any rewrite.
———
Phase 1: Go Gateway (binary protocol fidelity)
- Implement binary parsing and encoding in Go.
- Map each opcode to a handler interface.
- For now, proxy handlers to legacy C servers (so clients keep working).
This becomes the compatibility anchor.
———
Phase 2: Go Core Monolith (first rewrite)
- Implement core modules in Go and progressively cut traffic over.
- Start with lobby/auth/deck APIs (lower risk).
- Add game loop later with deterministic state checks.
———
Phase 3: Data Migration
- Introduce Postgres schemas.
- Mirror writes (old → new), then flip reads.
- Eventually remove Couchbase.
———
Why this fits your preferences
- Only Go + TS.
- Monolith first with future separation if needed.
- Fully off C while maintaining client compatibility.