FastAPI: choosing a Python framework without the sales pitch

So let's talk about what you are actually choosing.

What FastAPI is, underneath

FastAPI is not a web framework in the way Django is. It is a thin layer that sits on top of two other projects: Starlette handles the HTTP and ASGI plumbing, and Pydantic handles data validation and serialization. FastAPI itself glues those together and generates OpenAPI schemas from your type hints.

That layering matters. When something breaks, you will often find yourself reading Starlette documentation, not FastAPI documentation. When validation behaves oddly, you are debugging Pydantic, not FastAPI. The framework is honest about this, but it means the surface you need to know is wider than the name suggests.

The payoff is that your function signatures become the contract. You write:

```python from fastapi import FastAPI from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel): name: str price: float

@app.post("/items/") async def create_item(item: Item) -> Item: return item ```

The `Item` model validates the request body, rejects bad input with a 422, and appears in the generated OpenAPI schema. No separate serializer, no separate schema file to keep in sync. That is the whole trick, and it is a good trick.

The cost of the trick

Type hints are now load-bearing. If you annotate loosely, or reach for `Any` because you are in a hurry, you lose validation and you lose the schema. FastAPI does not stop you. It just quietly gives you less than you paid for.

Async is the same story. FastAPI supports `async def` endpoints and sync ones side by side. Sync endpoints run in a threadpool, which is fine for moderate load and terrible if you forget that a blocking database driver inside an `async def` will stall the entire event loop. Nothing warns you. The request just gets slow, and then everything gets slow.

Pydantic v2, which is what you want on any new project, is fast because its core is written in Rust. Pydantic v1 is pure Python and noticeably slower on large payloads. If you inherit a codebase, check which one you are on before you benchmark anything. Mixing them across dependencies is a common source of confusing errors.

Where it fits, and where it does not

FastAPI is at its best when the job is a JSON API consumed by something you also control: a frontend, a mobile app, an internal service. The automatic docs are genuinely useful for that, and the dependency injection system is small enough to reason about in an afternoon.

It is a poor fit for a server-rendered site with forms, sessions, and an admin panel. Django gives you all of that in the box, with an ORM, migrations, and an authentication system that has survived two decades of production. FastAPI gives you none of it. You will assemble those pieces yourself, and the assembly is where the time goes.

Flask sits in between. Smaller than Django, less opinionated than FastAPI, and stable in a way that makes it easy to hand a codebase to someone else. If your team is not comfortable with type hints and async, Flask will cost you less in onboarding, even if it costs you more in boilerplate later.

The deployment question

FastAPI runs on an ASGI server. Uvicorn is the usual choice, and for production you typically put Gunicorn in front of it with Uvicorn workers, or run Uvicorn directly behind a reverse proxy. The commands are not complicated, but they are not optional either.

```bash gunicorn main:app \ --workers 4 \ --worker-class uvicorn.workers.UvicornWorker \ --bind 0.0.0.0:8000 ```

Four workers is a starting point, not a recommendation. The right number depends on whether your endpoints are CPU-bound or waiting on I/O, and you will only know by measuring. Pick wrong and you either waste memory or queue requests behind a busy worker.

Behind that you need a reverse proxy for TLS, and something to keep the process alive when it crashes. Which it will. Every long-running service does.

Self-hosting this stack is entirely reasonable, right up until it is not. The moment a certificate expires at an inconvenient hour, you are not the person waiting for support. You are the support. That is a fine trade if you enjoy it, and a bad one if you do not.

What to actually decide

The question is not whether FastAPI is good. It is. The question is whether the specific shape of its goodness matches the shape of your problem.

If you are building a typed, async, JSON-first API and your team already writes modern Python, FastAPI will feel like less work than the alternatives. If you need an admin interface, sessions, and a mature ORM without assembling them, Django is the honest answer. If you want something small and boring that will still make sense in five years, Flask has not gone anywhere.

Pick based on what you are willing to maintain, not on what benchmarks well on a Tuesday. The framework you choose is the one you will be debugging at an hour you did not plan for.