Workshop · floor model for Survey of Software 1.241

layer cake

FastAPI is Starlette with a layer on top — the same library underneath, doing the same routing. That layer costs about four times the framework it sits on. The usual explanation for the cost is the validation. Race them both in this tab, then measure the validation on its own, and watch that explanation fall over.

Everything runs here, in your browser, on your machine. No server is involved — which is the point, and is explained below.

Plain language. Switch to Engineering for versions, byte counts and the measurements behind each claim.

The whole answer, first

Three numbers. The first is what the extra layer costs you. The second is what people think it is spent on. The third is what it is actually spent on.

Measured for the survey on one machine: aarch64, CPython 3.12.3, seven rounds of 2,000 requests, minimum of per-round means, no socket and no server. The race below re-measures the first two on yours.

Why there is no server on this page

A web framework normally sits behind a program that owns the network connection. That program is a separate choice, and mixing the two is how almost every published comparison of these frameworks goes wrong: "FastAPI is faster than Flask" is usually FastAPI-plus-one-server against Flask-plus-a-different-one. Two things changed, one number reported.

So this page removes the server entirely and hands the request straight to the framework. What you are timing is routing, reading the number out of the address, running the handler, and turning the answer back into text — the framework, and nothing underneath it.

The ASGI callable is driven directly with a scope dict. No socket, no uvicorn, no load generator, so no server variable to hold constant. This is exactly survey 1.241's scope; the server is survey 1.242's. It also means throughput under concurrency is not measured here or in the survey — that needs a socket and a load generator, and it is deferred.

A browser tab has no event loop you are allowed to block, so the request coroutine is stepped by hand. It completes on the first step: a handler that returns a dict never suspends. If one ever awaited real I/O, this page would raise rather than quietly report a wrong number.

Where the cost is not

If reading the message is the work, then checking it is extra work on top — so validation is a tax, and a hot path should skip it. That is the reasoning, and measuring it takes it apart.

Checking the message and reading it is faster than reading it without checking. The checking library reads it in one pass in compiled code; the standard library builds an entire throwaway object first. Validation does not sit on top of the parser. It replaces it.

Both are compiled. pydantic.BaseModel.model_validate_json parses in Rust and constructs the validated object in a single pass, never materializing the intermediate dict that json.loads spends its time on. The direction of this result is structural; the exact ratio depends on your machine, which is why you are about to measure it on yours.

And what the checking is actually for

Speed is the least interesting thing about it. The reason to describe the shape you expect is that anything not matching is refused before your code runs — with a message saying which field and why.

Take this to an AI

Floor model for Survey of Software 1.241 — Python Web Frameworks. The survey's own measurements, the recipe and the raw numbers are in its S2-comprehensive/bench/. Everything on this page ran in your browser.