3 ms·

TBH, the FastAPI "docs" are at https://github.com/polarsource/polar/tree/main/server https://github.com/polarsource/polar/tree/main/server If you want to actua

TBH, the FastAPI "docs" are at https://github.com/polarsource/polar/tree/main/server https://github.com/polarsource/polar/tree/main/server 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.

ilumanty 1y ago
FastAPI used to have an emoji-ridden docs page for concurrency. Criticism was not handled well. This made it clear to me that something about the project is off. https://github.com/fastapi/fastapi/discussions/6656 https://github.com/fastapi/fastapi/discussions/6656
- stackskipton 1y ago
  Tiangolo is type who wants to do it his way without a ton of input . One of reasons Litestar was developed.
rmonvfer 1y ago
Thank you! I’m actually pretty happy with what I’ve built tbh and how far has FastAPI taken us but this repo is proof that you have to reinvent the wheel if you want to build something serious. 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.
- whilenot-dev 1y ago
  > you have to reinvent the wheel if you want to build something serious [...] 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.
deleted 1y ago
[deleted]
arthurcolle 1y ago
Iam-abbas has a good FastAPI boilerplate
- whilenot-dev 1y ago
  If you're referring to this[0] GitHub project I'd highly disagree. I will never understand the minds of people that structure their apps like this: 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 A structure around mini apps always turns out to be more beneficial for keeping boundaries intact in the long run: apps ├── tasks │ ├── controller.py │ ├── models.py │ ├── repository.py │ ├── schemas.py │ └── service.py └── users ├── controller.py ├── models.py ├── repository.py ├── schemas.py └── service.py [0]: https://github.com/iam-abbas/FastAPI-Production-Boilerplate https://github.com/iam-abbas/FastAPI-Production-Boilerplate
  - hynek 1y ago
    The fancy word for that is Vertical Slice Architecture btw and it's the only way for complex apps that doesn't end in chaos.
    - shakna 1y ago
      Bogard's example for a poor fit for VSA, in the famous blogpost, was specifically controllers. > 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.

ilumanty 1y ago

FastAPI used to have an emoji-ridden docs page for concurrency. Criticism was not handled well. This made it clear to me that something about the project is off. https://github.com/fastapi/fastapi/discussions/6656 https://github.com/fastapi/fastapi/discussions/6656

stackskipton 1y ago
Tiangolo is type who wants to do it his way without a ton of input . One of reasons Litestar was developed.

rmonvfer 1y ago

Thank you! I’m actually pretty happy with what I’ve built tbh and how far has FastAPI taken us but this repo is proof that you have to reinvent the wheel if you want to build something serious. 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.

whilenot-dev 1y ago
> you have to reinvent the wheel if you want to build something serious [...] 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.

deleted 1y ago

[deleted]

arthurcolle 1y ago

Iam-abbas has a good FastAPI boilerplate

whilenot-dev 1y ago
If you're referring to this[0] GitHub project I'd highly disagree. I will never understand the minds of people that structure their apps like this: 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 A structure around mini apps always turns out to be more beneficial for keeping boundaries intact in the long run: apps ├── tasks │ ├── controller.py │ ├── models.py │ ├── repository.py │ ├── schemas.py │ └── service.py └── users ├── controller.py ├── models.py ├── repository.py ├── schemas.py └── service.py [0]: https://github.com/iam-abbas/FastAPI-Production-Boilerplate https://github.com/iam-abbas/FastAPI-Production-Boilerplate
- hynek 1y ago
  The fancy word for that is Vertical Slice Architecture btw and it's the only way for complex apps that doesn't end in chaos.
  - shakna 1y ago
    Bogard's example for a poor fit for VSA, in the famous blogpost, was specifically controllers. > 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.