What are your experiences with using Starlette or FastAPI in production?

Question

I'm currently evaluating Python frameworks for a new project. I've built a number of applications with Flask / Django over the years, but also recently discovered FastAPI, which is built on Starlette. I tried it out for a small hobby app locally and enjoyed the experience so far. I liked how you could define types with Pydantic, the dependency injection, and how it seemed a little easier to bootstrap and form a project structure vs. flask. The auto API docs are great as well. Also the FastAPI documentation itself seemed very thorough and had great examples for authentication, docker images, boilerplates, etc. The project and docs feel mature.That said, I don't see as much written about FastAPI and Starlette. I want to recommend it for a major project. Is there a large community around Starlette/FastAPI? Have you used it for large mission critical projects with many users? Would love to hear more about real world usage.

tiangolo · Accepted Answer

Here's some extra background that might help understanding where they come from.
The creator of Django-Rest-Framework, Tom Christie, created a new API framework with what he thought would be the best approach for building APIs in modern Python. It was called APIStar.
APIStar had to deal with some complexities underneath like supporting WSGI (the same used by Flask and Django) and ASGI, the new standard, etc. So, at some point, Tom decided that a new approach was needed. So, he created a new framework/toolkit form scratch, based on ASGI, called Starlette. The server part of APIStar was deprecated and from then on APIStar was only a set of tools for OpenAPI validation.
Starlette was made to be a minimal micro-framework and toolkit at the same time, so that other tools could be built on top of it, but providing a very solid foundation, and the best performance available in Python, on par with NodeJS and Go.
Then, FastAPI was created on top of Starlette, inheriting a lot of the ideas form APIStar (that actually come from even before, with Hug) and updating/improving them, to use standard Python type hints, dependency injection, OpenAPI with docs by default, etc.
About community, you can check the FastAPI Gitter chat, it has a lot of people and there's always someone asking questions and many great community members helping too.
And yeah, FastAPI is being used for what could be called major projects, e.g. Microsoft APIs for Windows (among others).
Disclaimer: I created FastAPI :)

Nextgrid · Answer

A past client of mine was using one of these relatively obscure frameworks. It's fine when it works (though I feel like the developer experience is much worse than let's say Django REST Framework) but when it breaks good luck figuring it out.
My recommendation is to just go with Django until the performance becomes a problem and it can't be solved by a "boring" solution such as throwing more hardware at it. Even after that, you can still squeeze out extra performance by using Serpy serialisers instead of the built-in DRF ones. Finally, if performance is still a problem then you could potentially use one of these frameworks. In most cases though, your underlying data store will be the bottleneck.
In my client's case, we were looking at a couple requests per second maximum, so they unnecessarily spent extra time learning and using an obscure framework without actually benefiting from it in any way.

aaai · Answer

FastAPI is awesome and dev experience is much much better than the heavy not-really-built-for-this-use-case Django + DRF mostruosity. But what I'm using it for is very low load... more like "internal use app" level of traffic. Can't say much about performance yet.But it's lovely and a pleasure to work with, most developer friendly thing I've ever touched lately!