Backend for the mixMaster restaurant ordering / recipes app. Modular monolith in Go — see docs/ARCHITECTURE.md for the data model, rules and endpoints.
- Go + chi — HTTP router
- sqlc — type-safe SQL → Go (no ORM magic)
- goose — SQL migrations
- PostgreSQL — database
- swaggo/swag + http-swagger — auto-generated Swagger from handler annotations
cmd/api/ entrypoint
internal/
config/ env config
httpx/ { data, error } response envelope
server/ router + route mounting
health/ liveness
users/ guests + favourites (implemented)
orders/ order / table lifecycle (implemented)
recipes/ recipes + components (implemented)
employees/ employees + restaurants (implemented)
db/ sqlc-generated code + queries/
db/migrations/ goose migrations
api/ generated swagger (docs.go, swagger.json/yaml)
All domains are wired end-to-end against PostgreSQL. The full flow — create restaurant → register employee → create recipe → open table → attach recipe → register guest → favourite — works through the API alone.
make tools # install swag, sqlc, goose (one-time)
make db-up # start postgres in docker
make migrate-up # apply migrations
make run # start the server on :8080Swagger UI: http://localhost:8080/swagger/index.html
Regenerate after changing SQL or handler annotations:
make sqlc # internal/db from db/migrations + internal/db/queries
make swag # api/ from handler annotations
make generate # bothgo test ./...The server smoke test (internal/server) verifies routing and that Swagger is served,
without needing a database.
.github/workflows/ci.yml runs on every push to main and PR:
gofmt— formatting checkgo vetsqlc diff— generated db code matches the SQL- swag regenerate +
git diff—api/is up to date with handler annotations go build+go test
Run the same checks locally before pushing:
make ci