Add spikard to Web Frameworks

[Goldziher]

Add spikard

Category: Web Frameworks

A single project, per the one-project-per-PR guideline.

Why it qualifies:

• 115 GitHub stars, MIT-licensed, actively maintained (commits within the last few days), repository ~16 months old.
• Fastest Python framework in our benchmark suite. 31 workloads via oha at concurrency 100, run by CI: spikard 12,623 avg RPS vs litestar 8,032, fastapi 6,418, robyn 6,012 — roughly 2x FastAPI and 2.1x Robyn, up to 2.7x on validation-heavy workloads. Results, per-category breakdown and the harness are in-repo.
• Distinct value: codegen-first and non-ASGI. Instead of writing Python and emitting an OpenAPI document from it, you start from a spec (OpenAPI 3.0, AsyncAPI 3.0, GraphQL SDL, OpenRPC, Protobuf) or from annotated SQL, and it generates typed handlers and validators. Routing, validation and middleware live in a Rust core; the Python layer is a thin binding.
• Clear README with installation and usage examples, plus a documentation site at spikard.dev.

Python-first in API with a Rust core — the same architecture as the already-listed robyn and xberg entries.

Maturity, stated plainly: an earlier version of this description called spikard "production-ready". That was wrong and I have corrected it. The project is experimental and pre-1.0 (0.17.0-rc), and its README says so — APIs still change between releases. If the "Stable — not alpha/beta/experimental" requirement is applied strictly then it does not qualify yet, and I am happy for this to be closed and resubmitted after 1.0.

[abdullahra634-dotcom]

Add spikard

Category: Web Frameworks → Asynchronous

Single project, per the one-project-per-PR guideline.

Why it qualifies:

• 105+ GitHub stars, MIT-licensed, and actively maintained (commits within the last few days).
• Production-ready release on PyPI with a clear README containing installation and usage examples.
• Distinct value: A non-ASGI web framework — a different architecture from every framework currently listed, which are ASGI-based (Litestar, Starlette) — built on an ultra-fast Rust core with type-safe routing.

It is a Python-first library (installable from PyPI) with a Rust core for performance — the same architecture as the already-listed xberg entry.

[JinyangWang27]

@Goldziher Thanks for the submission. My main concern is: what does Spikard offer Python developers that is meaningfully different from FastAPI?

The proposed description mentions a non-ASGI architecture, a Rust core, performance, and type-safe routing, but it does not clearly explain the practical benefit of choosing Spikard over an established framework such as FastAPI. FastAPI already provides type-based request validation, automatic OpenAPI documentation, security utilities, WebSocket support, dependency injection, and access to the wider Starlette and ASGI ecosystem.

Could you expand the PR description to clarify:

• which Python use cases Spikard handles better than FastAPI;
• which FastAPI or ASGI capabilities are unavailable or work differently;
• examples of real Python projects choosing Spikard for these reasons.

The project may be technically distinct internally, but for inclusion in awesome-python, the PR should establish that it offers Python users a distinct practical value rather than being another typed API framework with a different runtime.

[mvmcbvzzbg-cloud]

Tendi nada

[abirkhan3323-source]

Could you expand on how spikard differs from or improves upon the existing web frameworks already listed (Django, Flask, FastAPI, Litestar, etc.)? The contribution guidelines ask what makes it uniquely awesome — a comparison would help reviewers evaluate this.

[Goldziher]

Good question. The short answer is performance and code generation — here's the detail.

Performance

In our benchmark suite (31 workloads, oha at concurrency 100, run by CI rather than on a laptop, with results and methodology in-repo):

Framework	Avg RPS	P50	P99
spikard (Python)	12,623	5.55 ms	38.39 ms
litestar	8,032	14.62 ms	19.18 ms
fastapi	6,418	16.43 ms	21.72 ms
robyn	6,012	16.85 ms	24.18 ms

That is roughly 2x FastAPI and 2.1x Robyn on average, rising to 2.7x on validation-heavy workloads (validated forms and JSON bodies) where the win comes from validation running in Rust rather than Python. Full per-category results and the harness are in the repository.

Architecture

What makes it fast is also what makes it different: routing, validation, middleware and lifecycle hooks are implemented once in a Rust core, and the Python layer is a thin binding over it.

Django and Flask are WSGI and sync-first. FastAPI, Litestar and Starlette are ASGI with validation in Python. The nearest neighbour architecturally is robyn, which shares the Rust-runtime-plus-Python-API shape — spikard is about twice its throughput.

Code generation

The differentiator beyond speed is that spikard is codegen-first. Rather than writing Python and emitting an OpenAPI document from it, you start from a specification — OpenAPI 3.0, AsyncAPI 3.0, GraphQL SDL, OpenRPC, Protobuf — or from annotated SQL, and it generates typed handlers and validators. So:

-- @name GetUser
-- @returns :one
-- @http GET /users/{id}
SELECT id, name, email FROM users WHERE id = $1;

produces the route, an OpenAPI 3.1 fragment, and a typed handler stub. There is also an MCP server, so a coding agent can drive the generators without a human typing commands.

I have updated the entry to describe this rather than the previous "ultra-fast", which was not substantiated.

One thing I should state plainly

The original PR description said "production-ready". I have since corrected the project's own README to say it is experimental and pre-1.0, with APIs still changing between releases, and I have updated this PR description to match.

If the "Stable — not alpha/beta/experimental" quality requirement is applied strictly, then spikard does not meet it yet. I would rather say that than argue around it. Happy for this to be closed and resubmitted after 1.0 if that is the call.