If you want to actually figure out how to scale FastAPI for a large-ish app, including auth, testing and all that stuff, all with modern practices, "how they do it in that repo" is probably a good way to start with.
In any case, that’s a treasure trove right there!, I actually had no idea Polar was open source, much less that it’s built on FastAPI!
It’s such a shame that the actual documentation doesn’t even scratch the surface, I would’ve saved so much time if they just included a disclaimer along the lines of “Hey, this architecture we are showing here it’s only valid for toy projects, you will need much more work to build a real production system” but again, I guess I’m the only one to blame.
The main benefit from micro frameworks like FastAPI/Flask/Express.js is that you must build your own framework! You can pick the building blocks that will make your life easier, instead of relying on choices that made the maintainer life in full-fledged frameworks like Django/Laravel/RoR bearable. Of course, you'd need to be comfortable building frameworks and doing that work additionally to the domain modeling - pick the right tool for the job and all.
This made it clear to me that something about the project is off.
app
├── controllers
│ ├── task.py
│ └── user.py
├── models
│ ├── task.py
│ └── user.py
├── repositories
│ ├── task.py
│ └── user.py
└── schemas
├── extras
│ ├── current_user.py
│ ├── health.py
│ └── token.py
├── requests
│ ├── tasks.py
│ └── users.py
└── responses
├── tasks.py
└── users.py
apps
├── tasks
│ ├── controller.py
│ ├── models.py
│ ├── repository.py
│ ├── schemas.py
│ └── service.py
└── users
├── controller.py
├── models.py
├── repository.py
├── schemas.py
└── service.py
> Sometimes these are still required by our tools (like controllers or ORM units-of-work) but we keep our cross-slice logic sharing to a minimum.
That's exactly where you shouldn't be using it! Relying on it as dogma will result in chaos.