On: Litestar is worth a look

[miki123211]

TBH, the FastAPI "docs" are at 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.

[rmonvfer → miki123211]

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 → rmonvfer]

> 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.

[ilumanty → miki123211]

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

[stackskipton → ilumanty]

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

[arthurcolle → miki123211]

Iam-abbas has a good FastAPI boilerplate

[whilenot-dev → arthurcolle]

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

[hynek → whilenot-dev]

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 → hynek]

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.