An opinionated, msgspec-first ASGI micro-framework for Python 3.13+.
Engineered for performance from the ground up
Strictly typed end to end
A joy to build on
GitHub · Documentation
jero is an AI-powered (a note on AI usage) framework that builds typed JSON/REST APIs from plain classes. Annotate your handlers with msgspec Structs — jero does the rest: routing, validation, serialization, auth, streaming, and resource lifecycle.
from msgspec import Struct
from jero import BaseApp, Resource
class Widget(Struct):
id: str
name: str
class WidgetPath(Struct):
widget_id: str
class WidgetResource(Resource, path="/widgets"):
async def read_one(self, path: WidgetPath) -> Widget: # GET /widgets/{widget_id}
return Widget(id=path.widget_id, name="gizmo")
class App(BaseApp):
async def wire(self) -> None:
self._include_resource(WidgetResource())
app = App()
granian --interface asgi myapp:app # or uvicorn, or any ASGI server
No decorators, no dict returns, no runtime surprises — the Struct types are the
request/response contract, and they're verified at startup.
Why jero?
| ⚡ Fast | The fastest Python ASGI framework across every workload in the benchmark. All introspection happens once, at startup; the request path is just dict lookup → decode → call → encode. |
| 🎯 Opinionated | One blessed way to do each thing, so you can't get it wrong. Contracts fail loud at startup with a precise WiringError, never quietly at runtime. |
| 🔒 Typed | Fully static under pyright-strict, leaning hard into modern Python typing — PEP 695 generics (JSONResponse[Body, Headers], BaseApp[Factory]), bounded type-params, generic inheritance, Protocols. A handler's signature is its schema, and the source of the generated OpenAPI spec. |
No DI container, either: dependencies are hand-wired in wire; the framework adds
only lifecycle — the one thing plain Python doesn't give you.
What you get
- Resources & Endpoints — REST CRUD by method name, or bare verbs for one-off routes.
- Bind by name, validated by msgspec —
json,params,path,headers,form,user; malformed → 400, schema-invalid → 422, all resolved once at startup. - Typed responses and typed headers —
JSONResponse[Body, Headers]keeps both schemas (no erasure),status_codeoverrides the status, andraw_headersis the escape hatch for cookies and the exotic tail. - Streaming, typed end to end — NDJSON, Server-Sent Events, and raw byte streams, with lifecycle teardown and client-disconnect handling done for you.
- Multipart forms & uploads — typed parts, file uploads, per-part headers.
- Auth checked at startup — the
usertype is verified against your authenticator before a single request is served, not at runtime. - OpenAPI 3.1, derived — one
_include_openapicall serves the spec and a Scalar UI, built from your types, docstrings, andmsgspec.Metaconstraints — no decorators. - Lifecycle without a DI container — hand-wire in
wire, open resources on exit stacks, group construction in aBaseFactory. - REST semantics for free — 404/400/422/401/405, auto
HEAD+OPTIONS; opt anyStructinto camelCase on the wire withrename="camel". - A real test story — a sync, in-process
TestClient(no network), streaming and typed WebSocket support, and afactory=seam for mocking.
Start with Getting Started, or browse the full Guide.
A real app
For anything real, a resource delegates to a service, and a Factory builds that
service — opening any resources it needs (HTTP clients, DB pools, …) on the app's
exit stacks, which jero closes in reverse at shutdown. The app is parameterised with
the factory type (BaseApp[Factory]), exposing it as self._factory in wire.
from dataclasses import dataclass
from msgspec import Struct
from msgspec.json import decode as json_decode
from msgspec.json import encode as json_encode
from pyreqwest.client import Client, ClientBuilder
from jero import BaseApp, BaseFactory, HTTPError, Resource
class WidgetNotFoundError(
HTTPError,
type="widget-not-found",
title="Widget not found",
status=404,
): ...
class WidgetPath(Struct):
widget_id: str
class WidgetIn(Struct):
name: str
class Widget(WidgetIn):
id: str
@dataclass
class WidgetService:
"""Owns the upstream HTTP client; built once by the factory."""
_client: Client
async def fetch(self, widget_id: str) -> Widget:
resp = await self._client.get(f"/widgets/{widget_id}").build().send()
if resp.status == 404:
raise WidgetNotFoundError()
return json_decode(await resp.bytes(), type=Widget)
async def create(self, data: WidgetIn) -> Widget:
request = self._client.post("/widgets").header("Content-Type", "application/json")
resp = await request.body_bytes(json_encode(data)).build().send()
return json_decode(await resp.bytes(), type=Widget)
@dataclass
class WidgetResource(Resource, path="/widgets"):
_service: WidgetService
# called as: POST /widgets
async def create(self, json: WidgetIn) -> Widget:
return await self._service.create(json)
# called as: GET /widgets/{widget_id}
async def read_one(self, path: WidgetPath) -> Widget:
return await self._service.fetch(path.widget_id)
class Factory(BaseFactory):
async def create_widget_service(self) -> WidgetService:
client = await self._aenter(
ClientBuilder().base_url("https://api.example.com").build()
)
return WidgetService(client)
class App(BaseApp[Factory]):
async def wire(self) -> None:
widget_service = await self._factory.create_widget_service()
self._include_resource(WidgetResource(widget_service))
app = App()
Performance / Benchmarks
In a side-by-side benchmark against ten other frameworks — Python (Django Bolt, Blacksheep, Robyn, Litestar, FastAPI, Flask, Django Ninja), Go (Gin), Bun (Elysia), and Java (Spring Boot) — jero is the fastest Python ASGI framework in every scenario tested, and the fastest Python framework outright on the proxy and database scenarios. Each panel below is scaled to its own fastest framework; the labels keep the absolute throughput:
On the pure framework hot path (a typed JSON GET):
| Framework | GET /info req/s |
Relative to jero |
|---|---|---|
| elysia (Bun) | 50.3k | 1.03× |
| gin (Go) | 50.1k | 1.02× |
| django-bolt | 49.6k | 1.01× |
| jero | 49.0k | 1.00× |
| blacksheep | 41.5k | 0.85× |
| robyn | 36.4k | 0.74× |
| spring-boot (Java) | 32.6k | 0.66× |
| litestar | 32.2k | 0.66× |
| fastapi | 24.5k | 0.50× |
| flask | 19.4k | 0.40× |
| django-ninja | 2.4k | 0.05× |
The top four finish within 3% of each other — on the pure framework path, jero runs at Go and Bun speed. Django Bolt's built-in Rust server edges that test by ~1% and wins the authed write outright, but on the proxy and database paths — where the request's time is spent beyond the framework — jero leads it. On the upstream-proxy scenario, with every Python framework on the same Rust-based HTTP client, jero is the fastest Python framework outright, within ~15% of Go while returning a typed, validated payload. On the database scenario Go pulls well clear, because there the bottleneck is the database driver, not the framework. jero stays the fastest Python option, but it isn't as fast as Go in general — and this doesn't claim it is.
These are favourable, constrained conditions — single worker, one dedicated core, best-of-N — and a microbenchmark is not your application. See all four scenarios in the Performance / Benchmarks docs, and the full harness — every framework's source and the complete methodology — at api-benchmarks.
Development
task install # create the venv and install pre-commit hooks
task check # lock check + ruff, pyrefly, deptry, pylint (via prek)
task test # run the test suite with coverage
See AGENTS.md for the design philosophy and the contract, and
style-guide.md for project conventions.
1 maintainer
Metadata
1 maintainer
Release files for jero 0.1.4
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| jero-0.1.4.tar.gz | 136.1 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| jero-0.1.4-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 274.6 kB
Release files / jero-0.1.4.tar.gz
| Download URL | jero-0.1.4.tar.gz |
|---|---|
| Size | 136.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
cc755fae311ec398416e2c2c1d810df2126f6254995f4ae323dfd98ac9266971
|
|
BLAKE2b-256 checksum How to use checksums |
7a5d3837e95c3f2076e325ed1a65f528451f8125e264f3664839c11177323766
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
uv/0.13.4 {"installer":{"name":"uv","version":"0.13.4","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Release files / jero-0.1.4-py3-none-any.whl
| Download URL | jero-0.1.4-py3-none-any.whl |
|---|---|
| Size | 138.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
5877ff6f65742fe0ed4e536590f2c9156fb819f7df4dfe897b99cb0fa20b10d4
|
|
BLAKE2b-256 checksum How to use checksums |
4407154d2408f9ad5bea610f385b2ab4fba9c3a8361acd0b7c45f4569898db0b
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
uv/0.13.4 {"installer":{"name":"uv","version":"0.13.4","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Security for jero 0.1.4
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
