♻️ Simplify local development workflow

.env

@@ -22,13 +22,12 @@ FIRST_SUPERUSER=admin@example.com
 FIRST_SUPERUSER_PASSWORD=changethis
 
 # Emails
-SMTP_HOST=
+SMTP_HOST=localhost
 SMTP_USER=
 SMTP_PASSWORD=
 EMAILS_FROM_EMAIL=info@example.com
-SMTP_TLS=True
-SMTP_SSL=False
-SMTP_PORT=587
+SMTP_TLS=False
+SMTP_PORT=1025
 
 # Postgres
 POSTGRES_SERVER=localhost

.pre-commit-config.yaml

@@ -64,7 +64,7 @@ repos:
         entry: bash ./scripts/generate-client.sh
         pass_filenames: false
         language: unsupported
-        files: ^backend/.*$|^scripts/generate-client\.sh$
+        files: ^backend/app/.*\.py$|^backend/pyproject\.toml$|^uv\.lock$|^frontend/openapi-ts\.config\.ts$|^scripts/generate-client\.sh$
 
       - id: add-release-date
         language: unsupported

README.md

@@ -17,7 +17,7 @@
   - 🤖 An automatically generated frontend client.
   - 🧪 [Playwright](https://playwright.dev) for End-to-End testing.
   - 🦇 Dark mode support.
-- 🐋 [Docker Compose](https://www.docker.com) for development and production.
+- 🐋 [Docker Compose](https://www.docker.com) for local services and deployment.
 - 🔒 Secure password hashing by default.
 - 🔑 JWT (JSON Web Token) authentication.
 - 📫 Email based password recovery.
@@ -222,7 +222,7 @@ Deployment docs: [deployment.md](./deployment.md).
 
 General development docs: [development.md](./development.md).
 
-This includes using Docker Compose, custom local domains, `.env` configurations, etc.
+This includes the local FastAPI and Vite workflow, Docker Compose services, custom local domains, `.env` configuration, and more.
 
 ## Release Notes
 

backend/README.md

@@ -5,9 +5,25 @@
 * [Docker](https://www.docker.com/).
 * [uv](https://docs.astral.sh/uv/) for Python package and environment management.
 
-## Docker Compose
+## Local Development
 
-Start the local development environment with Docker Compose following the guide in [../development.md](../development.md).
+Run the backend locally and connect it to PostgreSQL in Docker Compose.
+
+From the project root, start PostgreSQL and Mailcatcher:
+
+```console
+$ docker compose up -d db mailcatcher
+```
+
+Then, from `./backend/`, install the dependencies, prepare the database, and start the development server:
+
+```console
+$ uv sync
+$ uv run bash scripts/prestart.sh
+$ uv run fastapi dev
+```
+
+The API is available at `http://localhost:8000`, with automatic interactive docs at `http://localhost:8000/docs`.
 
 ## General Workflow
 
@@ -35,66 +51,32 @@ There are already configurations in place to run the backend through the VS Code
 
 The setup is also already configured so you can run the tests through the VS Code Python tests tab.
 
-## Docker Compose Override
+## Full Stack with Docker Compose
 
-During development, you can change Docker Compose settings that will only affect the local development environment in the file `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:
+To run the backend and built frontend in Docker Compose:
 
 ```console
 $ 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.
+The application is available at `http://localhost:8000`.
 
-To get inside the container with a `bash` session you can start the stack with:
+### Docker Compose Override
 
-```console
-$ docker compose watch
-```
+The `compose.override.yml` file contains local settings for published ports, source synchronization, automatic image rebuilds, and backend reloads. Docker Compose applies it automatically when you run `docker compose` without an explicit file list.
 
-and then in another terminal, `exec` inside the running container:
+To open a shell in the backend container:
 
 ```console
 $ docker compose exec backend bash
 ```
 
-You should see an output like:
-
-```console
-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.
-
-```console
-$ fastapi run --reload app/main.py
-```
-
-...it will look like:
-
-```console
-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:
+To test the backend from the `backend` directory, run:
 
 ```console
-$ bash ./scripts/test.sh
+$ uv run bash ./scripts/test.sh
 ```
 
 The tests run with Pytest, modify and add tests to `./backend/tests/`.
@@ -123,30 +105,22 @@ When the tests are run, a file `htmlcov/index.html` is generated, you can open i
 
 ## 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:
-
-```console
-$ docker compose exec backend bash
-```
+Make sure you create a revision of your models and upgrade the database with that revision every time you change them. From the `backend` directory, use `uv` to run Alembic against the PostgreSQL container:
 
 * 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.:
+* After changing a model (for example, adding a column), create a revision:
 
 ```console
-$ alembic revision --autogenerate -m "Add column last_name to User model"
+$ uv run 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):
 
 ```console
-$ alembic upgrade head
+$ uv run 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:

compose.override.yml

@@ -71,7 +71,6 @@ services:
       SMTP_HOST: "mailcatcher"
       SMTP_PORT: "1025"
       SMTP_TLS: "false"
-      EMAILS_FROM_EMAIL: "noreply@example.com"
 
   mailcatcher:
     image: schickling/mailcatcher

compose.yml

@@ -70,9 +70,6 @@ services:
       SMTP_USER: ${SMTP_USER}
       SMTP_PASSWORD: ${SMTP_PASSWORD}
       EMAILS_FROM_EMAIL: ${EMAILS_FROM_EMAIL}
-      SMTP_TLS: ${SMTP_TLS}
-      SMTP_SSL: ${SMTP_SSL}
-      SMTP_PORT: ${SMTP_PORT}
       POSTGRES_SERVER: db
       POSTGRES_PORT: ${POSTGRES_PORT}
       POSTGRES_DB: ${POSTGRES_DB}

development.md

@@ -1,76 +1,85 @@
 # FastAPI Project - Development
 
-## Docker Compose
+## Local Development
+
+For local development, run PostgreSQL and Mailcatcher with Docker Compose, and run the FastAPI and Vite development servers locally.
 
-* Start the local stack with Docker Compose:
+Start the supporting services:
 
 ```bash
-docker compose watch
+docker compose up -d db mailcatcher
 ```
 
-* Now you can open your browser and interact with these URLs:
-
-Application, with the frontend and API served by FastAPI: <http://localhost:8000>
-
-Automatic interactive API documentation with Swagger UI: <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):
+Then, from the `backend` directory, install the dependencies and prepare the database:
 
 ```bash
-docker compose logs
+uv sync
+uv run bash scripts/prestart.sh
 ```
 
-To check the logs of a specific service, add the name of the service, e.g.:
+Start the FastAPI development server:
 
 ```bash
-docker compose logs backend
+uv run fastapi dev
 ```
 
-## Mailcatcher
+In another terminal, from the project root, install the frontend dependencies and start the Vite development server:
 
-Mailcatcher is a simple SMTP server that catches all emails sent by the backend during local development. Instead of sending real emails, they are captured and displayed in a web interface.
+```bash
+bun install
+bun run dev
+```
 
-This is useful for:
+Now you can open these URLs:
 
-* Testing email functionality during development
-* Verifying email content and formatting
-* Debugging email-related functionality without sending real emails
+Frontend development server: <http://localhost:5173>
 
-The backend is automatically configured to use Mailcatcher when running with Docker Compose locally (SMTP on port 1025). All captured emails can be viewed at <http://localhost:1080>.
+Backend API: <http://localhost:8000>
 
-## Local Development
+Automatic interactive API documentation with Swagger UI: <http://localhost:8000/docs>
 
-The Docker Compose files are configured so that each supporting service is available in a different port in `localhost`.
+Mailcatcher: <http://localhost:1080>
 
-FastAPI serves the built frontend and the API as one application at `http://localhost:8000`. The API routes live under `/api`.
+The frontend development server uses the backend at `http://localhost:8000`, as configured in `frontend/.env`.
 
-For frontend development with live reload, you can still run the local Vite development server separately.
+### Frontend Served by FastAPI
 
-Start the local frontend development server with:
+Build the frontend from the `frontend` directory:
 
 ```bash
-bun run dev
+bun run build
 ```
 
-Or you could stop the `backend` Docker Compose service:
+The build is written to `backend/app/frontend` and served by FastAPI at <http://localhost:8000>. Rebuild the frontend after making frontend changes.
 
-```bash
-docker compose stop backend
-```
+## Full Stack with Docker Compose
 
-And then you can run the local development server for the backend:
+To run the backend and built frontend in Docker Compose:
 
 ```bash
-cd backend
-fastapi dev app/main.py
+docker compose watch
 ```
 
+Now you can open these URLs:
+
+Application, with the frontend and API served by FastAPI: <http://localhost:8000>
+
+Automatic interactive API documentation with Swagger UI: <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>
+
+Mailcatcher: <http://localhost:1080>
+
+Stop a locally running FastAPI server before starting the Compose backend because both use port `8000`.
+
+**Note**: The first time you start the stack, it might take a minute to be ready while the backend waits for the database and configures everything. To monitor it, use `docker compose logs`, or `docker compose logs backend` for the backend service.
+
+## Mailcatcher
+
+Mailcatcher captures emails sent during local development instead of delivering them. The local backend connects to it at `localhost:1025`, and the Compose backend connects to the `mailcatcher` service. Captured emails are available at <http://localhost:1080>.
+
 ## 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, adminer, etc).
@@ -107,7 +116,7 @@ And there's also a `compose.override.yml` with overrides for development, for ex
 
 The `compose.deploy.yml` file contains the deployment-specific settings, including HTTPS and automatic certificate handling. It is explicitly combined with `compose.yml` when deploying the application.
 
-These Docker Compose files use the `.env` file containing configurations to be injected as environment variables in the containers.
+The backend reads local settings from the `.env` file. Docker Compose also uses it for variable interpolation and passes the settings each container needs.
 
 They also use some additional configurations taken from environment variables set in the scripts before calling the `docker compose` command.
 
@@ -119,11 +128,11 @@ docker compose watch
 
 ## The .env file
 
-The `.env` file is the one that contains all your configurations, generated keys and passwords, etc.
+The `.env` file contains the shared local defaults, generated keys, passwords, and other configuration. Its hostnames use `localhost` for processes running on your machine. Docker Compose overrides hostnames such as the database and SMTP server with their Compose service names.
 
 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 `compose.yml` file to read that specific env var instead of reading the `.env` file.
+One way to do it could be to add each environment variable to your CI/CD system.
 
 ## Pre-commits and code linting
 

frontend/README.md

@@ -15,7 +15,9 @@ bun run dev
 
 * Then open your browser at http://localhost:5173/.
 
-Notice that this live server is not running inside Docker, it's for local development, and that is the recommended workflow. Once you are happy with your frontend, you can build the backend Docker image and start it, to test the production-like setup where FastAPI serves the built frontend at `http://localhost:8000`.
+Run the backend locally with `uv run fastapi dev` and PostgreSQL in Docker Compose. See [../development.md](../development.md) for the complete setup.
+
+To serve the frontend with FastAPI, run `bun run build` from the `frontend` directory and open `http://localhost:8000`. To run the full stack with Docker Compose, use `docker compose watch`.
 
 Check the file `package.json` to see other available options.
 
@@ -33,14 +35,6 @@ If you are developing an API-only app and want to remove the frontend, you can d
 
 Done, you have a frontend-less (api-only) app. 🤓
 
----
-
-If you want, you can also remove the `FRONTEND_HOST` environment variable from:
-
-* `.env`
-
-But it would be only to clean them up, leaving them won't really have any effect either way.
-
 ## Generate Client
 
 ### Automatically
@@ -56,9 +50,9 @@ bash ./scripts/generate-client.sh
 
 ### Manually
 
-* Start the Docker Compose stack.
+* Make sure the backend is running.
 
-* Download the OpenAPI JSON file from `http://localhost/api/v1/openapi.json` and copy it to a new file `openapi.json` at the root of the `frontend` directory.
+* Download the OpenAPI JSON file from `http://localhost:8000/api/v1/openapi.json` and copy it to a new file `openapi.json` at the root of the `frontend` directory.
 
 * To generate the frontend client, run: