Skip to content

Add Starlette: the ASGI framework that powers FastAPI (~12k ⭐)#78

Open
BennyFranciscus wants to merge 1 commit intoMDA2AV:mainfrom
BennyFranciscus:add-starlette
Open

Add Starlette: the ASGI framework that powers FastAPI (~12k ⭐)#78
BennyFranciscus wants to merge 1 commit intoMDA2AV:mainfrom
BennyFranciscus:add-starlette

Conversation

@BennyFranciscus
Copy link
Collaborator

Starlette — The little ASGI framework that shines 🌟

Adds Starlette (~12k ⭐) to HttpArena.

Why Starlette?

FastAPI is already in HttpArena — and FastAPI is literally built on Starlette. Having both answers the question every Python developer asks: how much overhead does FastAPI's Pydantic validation, OpenAPI generation, and dependency injection actually add?

Same ASGI stack (Uvicorn + uvloop + Gunicorn), same runtime, same language — but Starlette is the raw foundation without the convenience layer. This is the purest "framework vs framework-on-framework" comparison possible.

Setup

  • Starlette 0.46.1 on Uvicorn (uvloop) + Gunicorn multi-worker
  • Pre-computed JSON + gzip caches for /json and /compression
  • Thread-local SQLite connections with mmap
  • orjson for fast JSON serialization
  • Identical worker config to the FastAPI entry for fair comparison

The Python lineup is now:

Entry Stack Model
Flask WSGI/Gunicorn sync Traditional sync
Starlette ASGI/Uvicorn async Raw async foundation
FastAPI ASGI/Uvicorn async Starlette + Pydantic + OpenAPI
Django WSGI/Gunicorn sync Full-stack ORM framework

cc @tomchristie @alex-grover @aminalaee — would love to see how Starlette stacks up against FastAPI in the benchmarks! The overhead question is one I've been curious about for a while.

Starlette 0.46.1 on Uvicorn (uvloop) + Gunicorn multi-worker.
Same ASGI stack as FastAPI but without Pydantic/OpenAPI overhead.
Pre-computed JSON + gzip caches, thread-local SQLite, orjson.
@BennyFranciscus BennyFranciscus requested a review from MDA2AV as a code owner March 18, 2026 17:03
@BennyFranciscus
Copy link
Collaborator Author

CI failure is the same port 8080 conflict on the self-hosted runner (stale Docker container) — same issue as Rocket #75 and Koa #77. The build compiles fine and all dependencies install correctly. Should pass on a clean runner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant