Two years after publishing the FastAPI Best Practices, I started to dislike some sections and wanted to make changes.
Today, I have made significant updates to its structure and key points:
• Organized content into clear chapters for better navigation, with sections sorted by importance.
• The section on sync routes only mitigated the problem with blocking I/O calls and didn't encourage the use of `async` routes. Now, the trade-offs are explicitly mentioned (thanks to tips by @marcelotryle).
• Removed unnecessary sections unrelated to FastAPI.
• Replaced Pydantic's BaseSettings recommendation with a practice of decoupling them, as it is widely used anyway.
• Upgraded code examples to Pydantic v2.
• The only linter recommended is Ruff by @astral_sh.
Check it out at https://t.co/qi2O4i11EU
My article on @FastAPI Best Practices has just been updated with a Chinese translation.
It’s great to see community contributions helping spread clean code practices around the world.
Link is below 👇
@Jeyffre Believing that vibe coding is dangerous significantly overestimates the level of code being pushed by humans.
Without AI those same devs would probably skip their homework and deploy that same bad code (just slower)
The FastAPI Production Template is now actually useful:
https://t.co/2TPcpFFK00
For some reason, I named it as a template, but the repo became an example project rather than something that can be easily forked and used to create new projects.
Now, it is truly a template and as lean as possible:
- Dropped `auth` module
- Dropped example external service module
- Dropped tests
- Dropped all linters, but ruff
- Dropped redis
- Added poetry
- Added ruff hooks for alembic migrations
- Added instructions to use `just`
- Refactored Dockerfile to use poetry
- Added docker compose file for prod
- Upgraded all dependencies
- Moved ruff configs to `ruff.toml`
- Refactored `gunicorn` conf to use Pydantic Settings
- Added SQLAlchemy methods for connection management