Skip to content

development.md

Latest commit

 

History

History
376 lines (223 loc) · 15 KB

development.md

File metadata and controls

376 lines (223 loc) · 15 KB
Raw

FastAPI Project - Backend

Requirements

  • Docker.
  • uv for Python package and environment management.

Docker Compose

FastAPI Project - Development

Docker Compose

  • Start the local stack with Docker Compose:
docker compose watch
  • Now you can open your browser and interact with these URLs:

API Service, JSON based web API based on OpenAPI: http://localhost:8000

Automatic interactive documentation with Swagger UI (from the OpenAPI backend): http://localhost:8000/docs

Adminer, database web administration: http://localhost:8080

Traefik UI, to see how the routes are being handled by the proxy: http://localhost:8090

Note: The first time you start your stack, it might take a minute for it to be ready. While the backend waits for the database to be ready and configures everything. You can check the logs to monitor it.

To check the logs, run (in another terminal):

docker compose logs

To check the logs of a specific service, add the name of the service, e.g.:

docker compose logs backend

Local Development

The Docker Compose files are configured so that each of the services is available in a different port in localhost.

For the backend and frontend, they use the same port that would be used by their local development server, so, the backend is at http://localhost:8000 and the frontend at http://localhost:5173.

This way, you could turn off a Docker Compose service and start its local development service, and everything would keep working, because it all uses the same ports.

For example, you can stop that frontend service in the Docker Compose, in another terminal, run:

docker compose stop frontend

And then start the local frontend development server:

cd frontend
npm run dev

Or you could stop the backend Docker Compose service:

docker compose stop backend

And then you can run the local development server for the backend:

cd backend
fastapi dev app/main.py

Docker Compose in localhost.tiangolo.com

When you start the Docker Compose stack, it uses localhost by default, with different ports for each service (backend, frontend, adminer, etc).

When you deploy it to production (or staging), it will deploy each service in a different subdomain, like api.example.com for the backend and dashboard.example.com for the frontend.

In the guide about deployment you can read about Traefik, the configured proxy. That's the component in charge of transmitting traffic to each service based on the subdomain.

If you want to test that it's all working locally, you can edit the local .env file, and change:

DOMAIN=localhost.tiangolo.com

That will be used by the Docker Compose files to configure the base domain for the services.

Traefik will use this to transmit traffic at api.localhost.tiangolo.com to the backend, and traffic at dashboard.localhost.tiangolo.com to the frontend.

The domain localhost.tiangolo.com is a special domain that is configured (with all its subdomains) to point to 127.0.0.1. This way you can use that for your local development.

After you update it, run again:

docker compose watch

When deploying, for example in production, the main Traefik is configured outside of the Docker Compose files. For local development, there's an included Traefik in docker-compose.override.yml, just to let you test that the domains work as expected, for example with api.localhost.tiangolo.com and dashboard.localhost.tiangolo.com.

Docker Compose files and env vars

There is a main docker-compose.yml file with all the configurations that apply to the whole stack, it is used automatically by docker compose.

And there's also a docker-compose.override.yml with overrides for development, for example to mount the source code as a volume. It is used automatically by docker compose to apply overrides on top of docker-compose.yml.

These Docker Compose files use the .env file containing configurations to be injected as environment variables in the containers.

They also use some additional configurations taken from environment variables set in the scripts before calling the docker compose command.

After changing variables, make sure you restart the stack:

docker compose watch

The .env file

The .env file is the one that contains all your configurations, generated keys and passwords, etc.

Depending on your workflow, you could want to exclude it from Git, for example if your project is public. In that case, you would have to make sure to set up a way for your CI tools to obtain it while building or deploying your project.

One way to do it could be to add each environment variable to your CI/CD system, and updating the docker-compose.yml file to read that specific env var instead of reading the .env file.

Pre-commits and code linting

we are using a tool called pre-commit for code linting and formatting.

When you install it, it runs right before making a commit in git. This way it ensures that the code is consistent and formatted even before it is committed.

You can find a file .pre-commit-config.yaml with configurations at the root of the project.

Install pre-commit to run automatically

pre-commit is already part of the dependencies of the project, but you could also install it globally if you prefer to, following the official pre-commit docs.

After having the pre-commit tool installed and available, you need to "install" it in the local repository, so that it runs automatically before each commit.

Using uv, you could do it with:

❯ uv run pre-commit install
pre-commit installed at .git/hooks/pre-commit

Now whenever you try to commit, e.g. with:

git commit

...pre-commit will run and check and format the code you are about to commit, and will ask you to add that code (stage it) with git again before committing.

Then you can git add the modified/fixed files again and now you can commit.

Running pre-commit hooks manually

you can also run pre-commit manually on all the files, you can do it using uv with:

❯ uv run pre-commit run --all-files
check for added large files..............................................Passed
check toml...............................................................Passed
check yaml...............................................................Passed
ruff.....................................................................Passed
ruff-format..............................................................Passed
eslint...................................................................Passed
prettier.................................................................Passed

URLs

The production or staging URLs would use these same paths, but with your own domain.

Development URLs

Development URLs, for local development.

Frontend: http://localhost:5173

Backend: http://localhost:8000

Automatic Interactive Docs (Swagger UI): http://localhost:8000/docs

Automatic Alternative Docs (ReDoc): http://localhost:8000/redoc

Adminer: http://localhost:8080

Traefik UI: http://localhost:8090

MailCatcher: http://localhost:1080

Development URLs with localhost.tiangolo.com Configured

Development URLs, for local development.

Frontend: http://dashboard.localhost.tiangolo.com

Backend: http://api.localhost.tiangolo.com

Automatic Interactive Docs (Swagger UI): http://api.localhost.tiangolo.com/docs

Automatic Alternative Docs (ReDoc): http://api.localhost.tiangolo.com/redoc

Adminer: http://localhost.tiangolo.com:8080

Traefik UI: http://localhost.tiangolo.com:8090

MailCatcher: http://localhost.tiangolo.com:1080

General Workflow

By default, the dependencies are managed with uv, go there and install it.

From ./backend/ you can install all the dependencies with:

$ uv sync

Then you can activate the virtual environment with:

$ source .venv/bin/activate

Make sure your editor is using the correct Python virtual environment, with the interpreter at backend/.venv/bin/python.

Modify or add SQLModel models for data and SQL tables in ./backend/app/models.py, API endpoints in ./backend/app/api/, CRUD (Create, Read, Update, Delete) utils in ./backend/app/crud.py.

VS Code

There are already configurations in place to run the backend through the VS Code debugger, so that you can use breakpoints, pause and explore variables, etc.

The setup is also already configured so you can run the tests through the VS Code Python tests tab.

Docker Compose Override

During development, you can change Docker Compose settings that will only affect the local development environment in the file docker-compose.override.yml.

The changes to that file only affect the local development environment, not the production environment. So, you can add "temporary" changes that help the development workflow.

For example, the directory with the backend code is synchronized in the Docker container, copying the code you change live to the directory inside the container. That allows you to test your changes right away, without having to build the Docker image again. It should only be done during development, for production, you should build the Docker image with a recent version of the backend code. But during development, it allows you to iterate very fast.

There is also a command override that runs fastapi run --reload instead of the default fastapi run. It starts a single server process (instead of multiple, as would be for production) and reloads the process whenever the code changes. Have in mind that if you have a syntax error and save the Python file, it will break and exit, and the container will stop. After that, you can restart the container by fixing the error and running again:

$ docker compose watch

There is also a commented out command override, you can uncomment it and comment the default one. It makes the backend container run a process that does "nothing", but keeps the container alive. That allows you to get inside your running container and execute commands inside, for example a Python interpreter to test installed dependencies, or start the development server that reloads when it detects changes.

To get inside the container with a bash session you can start the stack with:

$ docker compose watch

and then in another terminal, exec inside the running container:

$ docker compose exec backend bash

You should see an output like:

root@7f2607af31c3:/app#

that means that you are in a bash session inside your container, as a root user, under the /app directory, this directory has another directory called "app" inside, that's where your code lives inside the container: /app/app.

There you can use the fastapi run --reload command to run the debug live reloading server.

$ fastapi run --reload app/main.py

...it will look like:

root@7f2607af31c3:/app# fastapi run --reload app/main.py

and then hit enter. That runs the live reloading server that auto reloads when it detects code changes.

Nevertheless, if it doesn't detect a change but a syntax error, it will just stop with an error. But as the container is still alive and you are in a Bash session, you can quickly restart it after fixing the error, running the same command ("up arrow" and "Enter").

...this previous detail is what makes it useful to have the container alive doing nothing and then, in a Bash session, make it run the live reload server.

Backend tests

To test the backend run:

$ bash ./scripts/test.sh

The tests run with Pytest, modify and add tests to ./backend/app/tests/.

If you use GitHub Actions the tests will run automatically.

Test running stack

If your stack is already up and you just want to run the tests, you can use:

docker compose exec backend bash scripts/tests-start.sh

That /app/scripts/tests-start.sh script just calls pytest after making sure that the rest of the stack is running. If you need to pass extra arguments to pytest, you can pass them to that command and they will be forwarded.

For example, to stop on first error:

docker compose exec backend bash scripts/tests-start.sh -x

Test Coverage

When the tests are run, a file htmlcov/index.html is generated, you can open it in your browser to see the coverage of the tests.

Migrations

As during local development your app directory is mounted as a volume inside the container, you can also run the migrations with alembic commands inside the container and the migration code will be in your app directory (instead of being only inside the container). So you can add it to your git repository.

Make sure you create a "revision" of your models and that you "upgrade" your database with that revision every time you change them. As this is what will update the tables in your database. Otherwise, your application will have errors.

  • Start an interactive session in the backend container:
$ docker compose exec backend bash

  • Alembic is already configured to import your SQLModel models from ./backend/app/models.py.

  • After changing a model (for example, adding a column), inside the container, create a revision, e.g.:

$ alembic revision --autogenerate -m "Add column last_name to User model"

  • Commit to the git repository the files generated in the alembic directory.

  • After creating the revision, run the migration in the database (this is what will actually change the database):

$ alembic upgrade head

If you don't want to use migrations at all, uncomment the lines in the file at ./backend/app/core/db.py that end in:

SQLModel.metadata.create_all(engine)

and comment the line in the file scripts/prestart.sh that contains:

$ alembic upgrade head

If you don't want to start with the default models and want to remove them / modify them, from the beginning, without having any previous revision, you can remove the revision files (.py Python files) under ./backend/app/alembic/versions/. And then create a first migration as described above.

Email Templates

The email templates are in ./backend/app/email-templates/. Here, there are two directories: build and src. The src directory contains the source files that are used to build the final email templates. The build directory contains the final email templates that are used by the application.

Before continuing, ensure you have the MJML extension installed in your VS Code.

Once you have the MJML extension installed, you can create a new email template in the src directory. After creating the new email template and with the .mjml file open in your editor, open the command palette with Ctrl+Shift+P and search for MJML: Export to HTML. This will convert the .mjml file to a .html file and now you can save it in the build directory.