Course Practicalities

Project Roadmap

One Project, Many Milestones

The study tracker project of this course is one application that grows over the whole course. You do not create a new project in each part. Instead, you keep extending the same project folder until it becomes the final submission.

Each part adds one bounded capability, so the project grows without becoming too large to understand.

The course also uses a second recurring schema context in many regular chapters: a course-platform schema that supports concept learning and SQL practice. This page is only about the study tracker side. Its purpose is to show how the project schema grows across the course.

Project Structure at a Glance

The project stays in one folder for the whole course. Even though the features change, the main structure stays quite stable:

  • compose.yaml starts PostgreSQL and the web application together.
  • start.sh waits for the database, applies migrations, and starts the app.
  • migrations/ contains schema and seed SQL files.
  • app/main.py contains the FastAPI routes.
  • app/db.py contains the database connection helper.
  • app/migrate.py applies migration files in a controlled order.
  • app/templates/ contains the Jinja templates used to render HTML.

You do not need to memorize all of this at once. The important point is that the project keeps the same general shape while the database features become richer.

One Request Through the Project

A small request such as GET /decks usually follows this path:

  1. the browser sends a request,
  2. FastAPI matches a route in app/main.py,
  3. the route opens a database connection through app/db.py,
  4. PostgreSQL runs the SQL query,
  5. the route passes the rows to a template,
  6. and the template renders HTML back to the browser.

That same request path appears again and again later in the course.

Local Workflow in Practice

A typical local development cycle looks like this:

  1. run docker compose up --build,
  2. let PostgreSQL become healthy,
  3. let start.sh apply the migrations,
  4. open the application in the browser,
  5. make a change to a route, query, template, or migration,
  6. refresh, re-run, or restart if needed,
  7. and verify the effect both in the browser and in the database when appropriate.

That is the practical rhythm behind each new or modified feature. You will get more comfortable with it as you go.

Part 1: Walking Skeleton

Starting point:

  • no running project yet

New capability:

  • a minimal study tracker starts with Docker Compose,
  • PostgreSQL is available,
  • the application connects to the database,
  • and one page renders seeded data.

What success looks like:

  • docker compose up --build starts the project,
  • /decks opens in the browser,
  • and you can point to the route, the SQL, and the template.

You’ll start the project from a walking skeleton that has the basic structure and one simple page. The checkpoint chapter of Part 1 materials will guide you through the first local setup.

A Useful Habit Throughout the Project

At the start of each new part, ask:

  1. What already works?
  2. What is the one new capability for this part?
  3. How will I know that the capability works from both the browser and the database perspective?

That small checkpoint makes the project much easier to manage over the whole course.

← Tools and Environments
Glossary →