Series: Pokemon Api (14 posts)

Setting up the Cargo workspace, crates, git repo, rustfmt config, and Makefile the rest of the series builds on.

Loading server config from the environment with envconfig, so nothing about the port or CORS rules lives in the binary.

Wiring the config from the last part into an Axum server, split across a binary entry point and a build_app function.

A liveness endpoint the container orchestrator can poll before the service has any dependencies to check.

Wiring CORS, request tracing, and a body size limit through tower-http, driven by the config we already loaded.

Adding a PostgreSQL connection pool with sqlx, config-driven like everything else, and running migrations on startup.

Sharing the pool and config with every handler through Axum's typed state, and finally finishing the /readyz endpoint.

A trait-based repository in the pokemon_service crate, so the code that talks to Postgres never has to know it's serving HTTP.

A service layer that owns validation and business rules, depending on the repository trait instead of Postgres directly.

The last layer: translating HTTP requests into service calls and service errors into status codes.

Generating an OpenAPI schema and interactive docs from the handlers we already wrote, with utoipa.

Closing the gaps in ApiError so every failure, not just the ones the service produces, returns the same JSON shape.

A pinned, multi-stage Dockerfile, graceful shutdown, and the gap between a container that runs and a service you could actually deploy.

Request IDs and custom tracing spans, the two things Middleware explicitly deferred, plus structured logs for production.