Overview
We have built a browser interface that requests, checks and displays API data. Part 3 follows those requests into the server. We will validate input, use PostgreSQL through shared repository modules, and separate request handling from application rules. Transactions, locks and an explicit clock then let us reason about changes made by more than one request.
Continue using the practice application (practice/) from Parts 1 and 2 for
chapter examples. Keep that work separate from the marketplace project.
Part structure
- Server-Side HTTP with Hono — Separate application behavior from its listener, construct responses, and test requests directly.
- API Contracts & Validation — Distinguish stored, public, validated, and compile-time shapes while checking arbitrary HTTP input.
- Database Access & Integration Testing — Use parameterized SQL, relational constraints, test-owned fixtures, and real PostgreSQL evidence.
- Repositories, Services & Testing — Separate HTTP, use-case, and persistence responsibilities and test each at an appropriate boundary.
- Resource APIs & Data Lifecycle — Define editable fields, relationships, bounded collections, deletion policy, and stale-write behavior.
- Transactions & Atomicity — Commit or roll back related writes together using a transaction-scoped connection.
- Concurrency, Races & Locks — Identify check-then-act races and test row-lock coordination with independent connections.
- Time, State & Idempotency — Model legal transitions, make decision time explicit, and preserve repeat-safe outcomes.
- Marketplace Project: Building the Auction API — Apply the part’s ideas through six cumulative server-side marketplace milestones.
- Recap and Feedback — Connect the server boundaries, review the resulting auction behavior, and give feedback.
Practice database progression
The practice application has its own database-migrations/ directory and database.
Keep 001_create_todos.sql from the walking skeleton. The following chapters add
small, independent resources to demonstrate different persistence decisions:
| Chapter | Migration | Purpose |
|---|---|---|
| 3.4 | 002_rooms.sql | lab_rooms: move room reads from memory to PostgreSQL. |
| 3.7 | 003_stock.sql | lab_stock: observe an atomic debit and credit between two rows. |
| 3.8 | 004_workshops.sql | lab_workshops and lab_registrations: coordinate competing registrations. |
| 3.9 | 005_workshop_deadlines.sql | Add an optional deadline to the existing workshops. |
If you already added a migration, use the next unused numeric version and retain the same dependency order.