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.

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.

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

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

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

Iam-abbas has a good FastAPI boilerplate

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

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.

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.

I'm starting out with API style apps. This post was great since it covered several architectural and tool points I'd not thought of.

I think I'll use LiteStar for my app now too.

Thanks for your good comment and I 2nd your thanks to the author.

> Then came the SQLModel problems. The author pushes it very hard in the FastAPI docs

No it doesn't? The front page for FastAPI contains a pretty lengthy tutorial with no mention of SQLModel. The only time SQLModel gets a significant mention is on a page explaining connecting a relational DB, but it makes it clear that any DB at all can be used. Something has to be chosen for the tutorial, so it makes sense the author would choose their own.

If SQLModel isn't right for you then you're the only person to blame. I've been through that tutorial before and settled on plain old SQLAlchemy.

Doesn't Litestar suffer from some of this too? Do you think Litestar would be better for building complex applications than FastAPI, despite less community adoption / documentation / discussion?

Is there really less documentation? FastAPI mostly has tutorials to get started and is light on deep/reference material. A single person can only do so much.

Documentation-wise I'm mainly comparing to Django, because I agree FastAPI actually quite light on reference docs too.

I've actually tried using litestar before and always been keeping an eye on it, but for a full fledged website needing forms, auth, etc. I find it hard to move away from just slightly tweaking Django for my needs - but still I feel drawn to Litestar as it's in between FastAPI and Django but still much closer to the former. I hope/believe in time I will feel comfortable migrating to Litestar for complex sites

For forms and auth style apps, Django will probably always be the better choice.

edit: reading the litestar docs, it even has a built-in event system! I spent a couple weeks building something I could use with FastAPI...

Looking at the docs and trying to figure out what this is for. Is it essentially when you want to break out of the "request lifecycle" and queue something to run after your response has already been returned?

It strikes me that I haven't used web frameworks a lot and never even questioned how that may not be an easy thing to do!

They seem to fill the same purpose as django's signals.