OXO Game API

Problem

Game operations need a single backend to manage players and levels, room bookings, an endless-challenge/prize-pool system, payment handling, and structured game-event logging — exposed through a consistent, well-documented REST API.

Approach

• —Exposes a versioned REST API (/api/v1) with five modules: player/level management, room and reservation management, endless challenges with a prize pool, game-log collection, and payment processing
• —Organized in a clean layered architecture — API handlers, a business-logic service layer, and GORM data models — with logging and CORS middleware and centralized routing
• —Persists data in PostgreSQL via GORM, including a JSONB game-log type, with an init.sql that creates tables, indexes, seed levels/players/rooms, and an initialized prize pool
• —One-command Docker Compose deployment (Go API + PostgreSQL with health checks and persistent volume), plus a /health endpoint and Postman collections with per-module test reports

Architecture

• —Layered Go project: api/ (HTTP handlers) -> services/ (business logic, validation, transactions) -> models/ (GORM models) with config/, db/, middleware/, and routes/ packages
• —Gin web framework with logging and CORS middleware and a centralized router registering all /api/v1 endpoints
• —PostgreSQL (Alpine) accessed through GORM, including a custom JSONB type for game logs; schema and seed data provisioned by scripts/init.sql
• —Containerized with a Dockerfile and docker-compose.yml orchestrating the API and Postgres (dependency health checks, persistent data volume, env-based config)
• —Documentation-driven: per-module Markdown test reports in doc/ and a Postman test collection; roadmap notes for Redis caching, JWT auth, request rate limiting, WebSocket, and Prometheus monitoring

Stack