Add a Django REST Framework API to the Tic Tac Toe Game

In this lesson I direct GPT-6 Astra in Codex CLI to add a Django REST Framework API to our tic tac toe project. I work in VS Code with NVDA, although screen-reader audio is muted in this recording. By the end, the API is running with two health checks. Player records and saved games come later.

Use the tic tac toe repository, with Docker Desktop running. My run the game lesson covers getting it onto your computer, and the PostgreSQL lesson explains the database service. The repository already includes this API, so you can run it and read the code without rebuilding it.

Before implementation, I give the coding tool a plan file and a concrete definition of done: Django REST Framework in its own container, one route that reports API health, and another route that makes a real request to PostgreSQL. I also ask it to account for Compose networking. The frontend will not store games in this step.

For your own changes, write down the files and behavior you expect, then review the proposed changes against that list. When the tool says it is done, that is when I start checking. In the recording, I copy the response into a new editor so I can read it alongside the generated files.

The back-end folder contains the Dockerfile, manage.py, pyproject.toml and the gaming_center Django project. I inspect the dependency list for Django, Django REST Framework and psycopg, then read settings.py, urls.py and health.py. Install from the dependency files and lockfile in your download, not from the version numbers I say in the video.

The API health view returns an OK response. The database view executes a small database query and handles a database failure separately. The Django REST Framework view documentation explains the function-based API view pattern used here.

For the current repository, the browser connects to the app on localhost:5173. Vite forwards /api/ requests to api:8000 inside Compose, and Django connects to database:5432. Inside a container, localhost means that container itself. Compose service names identify the other services on the network. See Docker's Compose networking guide.

From the repository root, start the services and read their status:

Wait for app, api and database to become healthy. The current README documents the setup. This is a local development setup with development passwords, so keep it on your own computer.

Open each address in your browser, keeping the trailing slash:

Both healthy responses contain {"status":"ok"}. The first tells you the API is responding. The second runs a query against PostgreSQL, and if the database is down it returns HTTP 503 with an unavailable status. That is why there are two checks: the first one can pass even when the database is not working.

As an additional check documented in the current project, run the Django checks and tests:

If a service fails, inspect its logs with docker compose logs --tail=100 api or the corresponding database service name. Keep the actual error and test result in your notes.

Run docker compose down from the project root when you are finished. Write down what was built, what you checked and what is left. Next on the list are the game models and routes, then connecting the frontend. My accessibility review looks at the game's interface with NVDA.