fastapi-starter VS full-stack-fastapi-template

For my new projects, I wanted a boilerplate which utilised the ecosystem as much as possible. So how's the new template better than the official template?

This project is a modification of the authentication flow of the awesome repository made by tiangolo at full-stack-fastapi-postgresql

FastAPI with a PostgreSQL database: https://github.com/tiangolo/full-stack-fastapi-postgresql/tree/master

Ha! I do write SQL since that's where I cut my teeth many years ago. But I mostly use stored procedures where possible. I prefer not to use ORMs - sorry I don't find that side work... I am not saying Django's was bad or inferior, just do not prefer it. For FastAPI - maybe you missed the various repos with everything you mentioned was missing (there are great ones directly from the maintainer as well as others). No more glue than what you find in all the modules in a large Django project, just maybe in different forms and flavors. Besides, we're here to talk about Rust, making me wonder why we're debating two Python projects. Yes, I fell in love with Django, the romance faded in 2018, and I moved on. Feel free to enjoy using it - I'm not trying to sway you away from it!

I've just recently switched to a structure that follows Netflix's Dispatch application after starting with https://github.com/tiangolo/full-stack-fastapi-postgresql and it feels way better and organized.

Honestly your easiest option for data gathering would be to create google spreadsheets/forms and give each municipality access. For a custom data entry platform I suggest looking for templates like this one and learning how to add custom logic to the boilerplate: https://github.com/tiangolo/full-stack-fastapi-postgresql

I would encourage you to take a look at this repo: https://github.com/tiangolo/full-stack-fastapi-postgresql This is a boilerplate of an application made with fastapi, prepared by the creator of the fastapi himself. You can even set it up yourself locally and have a look how it’s organised. I know it has a lot of different services included, but I find the fastapi part itself to be well thought. Inside the api directory you can notice another folder named api_v1, so you can have multiple versions of your API routes when needed, with the general code in other places that is more generic and can be reused in all your different API versions. The schemas are separated from the models and models itself have different classes depending on what you would actually like to do with the data. The migrations are managed with alembic based on schemas rather than models itself. The settings are a python class that implicitly reads the .env file in your project’s directory. And many, many other interesting patterns to explore. Too much to write in one comment to be honest.