Phase 1 — Core API
Phase 1 established the foundation of the Battleship API — player registration, game creation, join flow, and ship placement with full validation.
Architecture
- 5-table relational schema: players, games, game_players, ships, moves — designed upfront to avoid migrations across future phases
- Integer-based identity reuse: POST /api/players returns the same player_id for the same display_name, so identity persists across games
- Raw parameterized SQL queries via the pg pool — no ORM, giving us full control over query structure and performance
- Database-level constraints enforce data integrity: display_name UNIQUE, composite primary key on game_players, foreign keys with CASCADE
- All validation returns proper HTTP status codes: 400 for input errors, 403 for identity issues, 404 for not found
My Contributions
Built the deployment pipeline on Render, configured the NeonDB connection with SSL, and wrote the Checkpoint B automated test script.