Revision · Part 1: The Blog Core
Part 1 builds the foundation everything else bolts onto: a working blog backend with real persistence and honest failures. This overview lays out the shape; the chapters fill in each slice as the build needs it.
What this part covered
Section titled “What this part covered”- Start with the right shape —
quillis a Cargo workspace from day one, not because a blog needs it, but because Parts 3–4 add a worker binary and shared crates, and it’s far easier to start with the shape than retrofit it. - A real REST API for posts — health probe plus full CRUD (list published/paginated, create a draft as 201, fetch by slug with 404, update and delete by id), every response JSON, every failure a correct status code.
- A deliberate stack, each piece justified — tokio for the async runtime, axum for typed extractors and tower middleware, sqlx for compile-time-checked Postgres queries with no ORM magic, serde for JSON, thiserror for one
AppError, and uuid/time for stable ids and timestamps. - Persistence done properly — connection pools, migrations as code, and a repository that keeps SQL out of the handlers.
- One error type that maps to HTTP — a single
AppErrorwithIntoResponseso?turns any failure into a correct status code, never a panic and never a leaked stack trace or internal detail. - Type it, don’t read it — the reference workspace at
rust/quill/is the answer key; you build your own, run it against local Postgres, and break it on purpose to feel the compiler’s (and HTTP client’s) objection.
The takeaway
Section titled “The takeaway”Part 1’s answer to the book’s thread is the least glamorous and most important: a clean shape and honest failures. A handler that can only return Ok or a typed error is the difference between a service you can operate and one that pages you at 3 a.m. Everything fancy in later parts assumes this foundation is solid. Next, Part 2 gives the backend a face with an Astro frontend.