Loading published curriculum…

21 · Capstone: demonstrate backend readiness / LESSON 102 OF 102

Capstone: a personal task manager API

Combine the course into one project you can demonstrate.

Before this lesson: Modular design, migrations, resilience, and release review

Understand the topic

Build authenticated, owner-scoped task CRUD with DTOs, validation, paginated filtering, PostgreSQL, migrations, tests, and health monitoring. Keep controllers thin and business changes transactional. Start as a modular monolith.

Document setup, environment variable names without values, authentication/CSRF flow, API examples, and test commands. Advanced next steps are caching, scheduling, messaging, OAuth2, and service decomposition once the core API is reliable.

EXAMPLE · TEXT

Acceptance contract

POST   /api/tasks                 -> 201 + Location
GET    /api/tasks?page=0&size=20   -> 200 + paginated DTOs
GET    /api/tasks/{id}            -> 200 or 404
PATCH  /api/tasks/{id}            -> 200 or 204
DELETE /api/tasks/{id}            -> 204

Invalid title                    -> 400
Missing identity                 -> login/401 per auth model
Another user's task              -> 403 or non-disclosing 404
Missing CSRF on cookie mutation  -> 403
GET /actuator/health              -> minimal response

What to expect

A clean checkout builds, tests, and runs with documented configuration. Users cannot access each other’s tasks and data survives restarts.

YOUR TURN

Put it into practice

  1. 01Implement every route and failure in the contract.
  2. 02Run tests against a clean database.
  3. 03Record a walkthrough of success, validation failure, denied access, and restart.

Pass a quiz or complete a lab to check today’s streak. Each lesson counts once per day, including when you review it later.

UNDER THE HOOD

Build the mental model

Backend readiness means designing, implementing, testing, and diagnosing a working system—not remembering annotations.

  1. 01Explain the entire path from request through security, validation, service, transaction, repository, and response. Identify which component owns each rule.
  2. 02Demonstrate the negative cases: malformed input, absent identity, wrong owner, missing resource, conflicting update, and unavailable database.
  3. 03Use the README and automated tests as evidence that another developer can operate the project without your IDE or private setup.

A mistake worth avoiding

A working happy-path demo is not proof of secure or reliable behavior.

DEBUGGING ROOM

Something broke. Where do you look?

The app works on the author’s laptop but nobody else can run it.

Before revealing the diagnosis, write down your first investigation step.

CHECK YOUR UNDERSTANDING

What is the strongest evidence of backend readiness?

Choose one answer

BUILD IT YOURSELF

Deliver a reviewable backend portfolio project

  1. 1.Implement the acceptance contract.
  2. 2.Include an API collection and automated tests.
  3. 3.Record a walkthrough and a debugging session.

Acceptance checklist

Lab completion is your self-report. Knowledge checks do not certify project quality.

RETRIEVE IT FROM MEMORY

Which failure path is least tested in your project, and how will you verify it?

Revisit this lesson in three days after a successful check or lab.

Ready for the next step?

Explain the whole request lifecycle and demonstrate the API.

Reading is separate from passing a knowledge check or completing a lab.

Go deeper · official references