Back to path
BeginnerTaskFlow · Project 1 of 13 ~3h· 5 milestones

Run it locally and understand it

You just cloned the TaskFlow repo: a React + Vite frontend, a FastAPI + SQLAlchemy backend, and a Postgres database.

Reading and running a multi-service local stackEnvironment variables and 12-factor config (VITE_API_URL, DATABASE_URL)TCP ports and how services find each other on localhostTracing a request through frontend, API, ORM, and databaseReading application logs to confirm behavior
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

TaskFlow runs end to end on your machine: Postgres on :5432 with a tasks table, FastAPI on :8000 serving GET /healthz and GET/POST /tasks, and the Vite dev server on :5173 rendering the task list. You can add and complete a task in the browser, watch the request appear in the backend logs, and explain in plain language every hop the request takes. You can also produce the production frontend build (dist/) and explain why it is different from the dev server.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

backend/.envbash
# Local Postgres connection string the FastAPI app reads at startup.
# Format: postgresql://USER:PASSWORD@HOST:PORT/DBNAME
DATABASE_URL=postgresql://taskflow:taskflow@localhost:5432/taskflow

Reading this file

  • DATABASE_URL=postgresql://This single variable is the only place the database location and credentials live, so you never hard-code them in Python.
  • taskflow:taskflowThe part before the colon is the database username and the part after is its password; both are 'taskflow' for local dev.
  • @localhost:5432The API connects to Postgres on your own machine (localhost) at the default Postgres port 5432.
  • /taskflowThe text after the last slash is the database name the app will create its tasks table inside.

Copy from backend/.env.example. This is the single source of the DB connection string the backend reads at startup.

That's 1 of 8 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Get a Postgres database running and reachable on :5432

    3 guided steps

    Everything downstream depends on the database existing. The backend reads DATABASE_URL at startup and connects immediately, so if Postgres is missing or the credentials are wrong, nothing else works. Getting this right first means every later error is about your code, not your environment.

  2. 2

    Start the FastAPI backend on :8000 and make /healthz return ok

    4 guided steps

    The backend is the keystone. It owns the contract the frontend depends on and the readiness signal the cloud depends on. Running it in a virtual environment keeps its dependencies isolated from your system Python, which is the same isolation principle a container gives you later.

  3. 3

    Run the Vite dev server on :5173 and connect it to the API

    4 guided steps

    The frontend is where a human actually interacts with TaskFlow, and VITE_API_URL is the wire that connects the browser to your API. Understanding that this variable is baked into browser code at build time (not read at runtime) is a concept that matters greatly when you deploy the static build to S3 or a CDN later.

  4. 4

    Trace one request end to end and read the logs

    4 guided steps

    This is the comprehension payoff of the entire rung. Once you can trace a request by hand, every future failure (a 502 from the ALB, a pod that fails readiness, a connection-pool exhaustion) becomes a question of 'which hop broke' rather than a mystery. Reading logs is the single most useful debugging skill in cloud work.

  5. 5

    Produce the production build (dist/) and understand why it differs

    4 guided steps

    In every cloud rung from here on, you do not ship the Vite dev server; you ship the static dist/ folder to S3, a CDN, or an nginx container. Understanding that dist/ is a frozen snapshot with VITE_API_URL already compiled in prevents a classic production bug: building with the wrong API URL and wondering why the deployed site calls localhost.

What's inside when you start

3 starter files, ready to clone
5 guided milestones
5 full reference solutions
8 code blocks explained line-by-line
5 "is it working?" checks
4 interview questions it prepares you for

You'll walk away with

All three services running locally at once: Postgres on :5432, FastAPI on :8000, Vite dev server on :5173, with a task added through the UI and visible in the database.
A working GET /healthz returning {"status":"ok"}, confirmed with curl, that will become the readiness probe in every later rung.
A short written request trace (4-6 lines) describing the path browser -> Vite -> :8000 -> SQLAlchemy -> Postgres -> back, backed by a Network tab entry, a uvicorn log line, and a Postgres row.
A production build in frontend/dist/ that you served as static files, plus a one-sentence note explaining why VITE_API_URL is baked in at build time.

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building