65 lines
1.9 KiB
Markdown
65 lines
1.9 KiB
Markdown
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.
|
|
|