Comparison with FastAPI

FastrAPI is designed as a drop-in replacement for FastAPI with significant performance improvements. This page provides a detailed comparison of the two frameworks.

Quick comparison

Area	FastAPI	FastrAPI	Winner
Dependency resolution	Runtime `inspect` + reflection every request	One-time parsing at decorator → pre-built injection plan	✅ FastrAPI
Fast-path for trivial endpoints	No special case: full kwargs/dependency work always	`is_fast_path` flag → skip deps, validation, kwargs	✅ FastrAPI
Route lookup speed	Starlette regex router (slows with many routes)	`papaya` concurrent hashmap → O(1) lookup	✅ FastrAPI
Middleware usability (Python)	`@app.middleware` often buggy / limited	Clean, working decorator + real execution	✅ FastrAPI
Background tasks reliability	Fire-and-forget, errors usually swallowed	Proper `JoinHandle` + error logging	✅ FastrAPI
WebSocket implementation	Starlette (solid but heavy)	Custom with bounded channels + clean async pump	✅ FastrAPI
Startup-time error detection	Almost everything deferred to runtime	Full signature + dependency analysis at decorator time	✅ FastrAPI
Concurrency & resource safety	asyncio + threadpool	Native Tokio + Rust memory & thread safety	✅ FastrAPI
Deployment footprint	Heavy (uvicorn + many deps)	Tiny Rust binary + optional Python runtime	✅ FastrAPI
Scaling to 10,000+ routes	Noticeable slowdown	Stays fast thanks to hashmap lookup	✅ FastrAPI
JSON serialization flexibility	Hard to swap (monkey-patch needed)	Trivial to plug orjson / sonic-rs / simdjson	✅ FastrAPI
`response_model=None` + raw Response return	Fully supported	Not yet supported	❌ FastAPI
`APIRouter` + `include_router()`	Yes, mature ecosystem	Not yet implemented	❌ FastAPI
`app.mount()` / `StaticFiles`	Yes	Not yet implemented	❌ FastAPI

FastrAPI wins on 11 out of 14 comparison points, with 3 features still in development.

Performance benchmarks

Real-world performance comparison using k6 load testing (20 VUs, 30s duration):

Throughput

FastrAPI

31,360 requests/sec

FastAPI (16 workers)

3,882 requests/sec

FastAPI (1 worker)

937 requests/sec

Latency comparison

# Average latency (lower is better)
FastrAPI:           0.59 ms   ⚡
FastAPI (16 workers): 4.84 ms   📊
FastAPI (1 worker):  21.08 ms   🐌

# P99 latency (lower is better)
FastrAPI:          11.12 ms   ⚡
FastAPI (16 workers): 81.20 ms   📊
FastAPI (1 worker):  93.42 ms   🐌

Performance multiplier: FastrAPI is ~33x faster than FastAPI with 1 worker and ~8x faster than FastAPI with 16 workers.

Architectural differences

Dependency resolution

# FastAPI resolves dependencies at every request
@app.get("/user/{user_id}")
def get_user(user_id: int, db = Depends(get_db)):
    # On EVERY request:
    # 1. Call inspect.signature()
    # 2. Analyze parameters
    # 3. Resolve dependencies
    # 4. Build kwargs
    return db.get_user(user_id)

FastrAPI’s approach eliminates repeated introspection overhead, resulting in significantly faster request processing.

Route lookup

FastAPI
FastrAPI

FastAPI uses Starlette’s regex-based router:

# Routes are matched using regular expressions
# Time complexity: O(n) where n = number of routes
# With 1,000 routes: ~1,000 regex matches per request
for pattern, handler in routes:
    if pattern.match(path):
        return handler

Impact: Performance degrades as you add more routes.

FastrAPI uses a concurrent hashmap from the papaya crate:

// O(1) constant-time lookup
// With 10,000 routes: still O(1)
pub static ROUTES: Lazy<PapayaHashMap<String, RouteHandler>> =
    Lazy::new(|| PapayaHashMap::with_capacity(128));

let handler = ROUTES.get(route_key, &guard);

Impact: Performance stays constant regardless of route count.

Async runtime

FastAPI: asyncio + GIL

FastAPI runs on Python’s asyncio:

# Python's GIL limits true parallelism
import asyncio

# Async functions still run on a single thread
async def handler():
    await some_io()  # Only I/O is truly concurrent
    do_cpu_work()    # GIL prevents parallel execution

Limited by the Global Interpreter Lock (GIL)
CPU-bound work blocks the event loop
Concurrency, but not true parallelism

FastrAPI: Tokio + thread pool

FastrAPI uses Tokio’s multi-threaded runtime:

// True parallelism with work-stealing scheduler
static PYTHON_RUNTIME: Lazy<tokio::runtime::Runtime> = Lazy::new(|| {
    tokio::runtime::Builder::new_multi_thread()
        .worker_threads(num_cpus::get().max(4).min(16))
        .enable_all()
        .build()
        .expect("Failed to create Python runtime")
});

Python handlers run in isolated thread pool
Tokio provides true multi-threaded parallelism
Work-stealing for efficient load balancing
GIL is released between requests

Middleware execution

Feature	FastAPI	FastrAPI
Decorator support	Limited, often buggy	Full support with `@app.middleware`
Layer ordering	Not guaranteed	Explicit, documented order
Performance	Python-only overhead	Rust layers + Python fallback
Built-in options	Basic CORS	CORS, GZip, Sessions, Trusted Host

Feature compatibility

Supported features

Features with full FastAPI compatibility

✅ Decorator syntax (@app.get, @app.post, etc.)
✅ Pydantic models for validation
✅ Dependency injection with Depends()
✅ Path parameters and query parameters
✅ Request/response models
✅ WebSockets
✅ Middleware (CORS, GZip, Sessions, Trusted Host)
✅ Background tasks
✅ Security utilities (OAuth2, JWT)
✅ Multiple response types (JSON, HTML, PlainText, Redirect)
✅ OpenAPI/Swagger documentation

Features in development

Features not yet implemented (coming soon)

⏳ APIRouter + include_router()
⏳ app.mount() for static files
⏳ response_model=None with raw Response returns
⏳ Lifespan events (@app.on_startup, @app.on_shutdown)
⏳ Exception handlers (@app.exception_handler())
⏳ Hot reloading / watchfiles integration
⏳ TestClient for testing
⏳ app.state for mutable app-wide state

Migration guide

Switching from FastAPI

Migration is designed to be seamless:

Update import

Change your import statement:

# Before
from fastapi import FastAPI

# After
from fastrapi import FastrAPI

Update class name

Rename the application class:

# Before
app = FastAPI()

# After
app = FastrAPI()

Update server command

Replace uvicorn with FastrAPI’s built-in server:

# Before
# uvicorn main:app --reload

# After
if __name__ == "__main__":
    app.serve("127.0.0.1", 8080)

Test and deploy

Your existing routes, dependencies, and Pydantic models should work without changes!

Known migration issues

Be aware of these differences:

Response models

FastrAPI doesn’t yet support response_model=None with raw Response objects:

# Not yet supported
@app.get("/redirect", response_model=None)
def redirect():
    return RedirectResponse("/new-url")

# Use type hints instead
@app.get("/redirect")
def redirect() -> RedirectResponse:
    return RedirectResponse("/new-url")

APIRouter

Sub-applications with APIRouter are not yet supported:

# Not yet available
from fastrapi import APIRouter
router = APIRouter(prefix="/api/v1")
app.include_router(router)

# Workaround: define routes directly on app
@app.get("/api/v1/endpoint")
def handler():
    return {"status": "ok"}

Static files

app.mount() for static file serving is not implemented:

# Not yet available
from fastapi.staticfiles import StaticFiles
app.mount("/static", StaticFiles(directory="static"))

# Workaround: use a reverse proxy (nginx, caddy)
# or wait for native support

When to use FastrAPI

Use FastrAPI when

You need maximum performance
You have high request volumes
You want lower latency
You’re building a new API
You don’t need APIRouter or static files
You want smaller deployment size

Stick with FastAPI if

You rely heavily on APIRouter
You need app.mount() for static files
You use many third-party FastAPI plugins
Your app uses advanced response model features
You need hot reloading in development
You’re not performance-constrained

Future roadmap

FastrAPI is actively closing the feature gap with FastAPI:

Q2 2025

APIRouter support
Static file serving
Hot reloading

Q3 2025

Exception handlers
Lifespan events
TestClient

Q4 2025

Response model enhancements
Plugin ecosystem
Advanced OpenAPI features

For the latest updates, check the GitHub repository.

Get Started

Core Concepts

Guides

Advanced

Comparison with FastAPI

Quick comparison

Performance benchmarks

Throughput

FastrAPI

FastAPI (16 workers)

FastAPI (1 worker)

Latency comparison

Architectural differences

Dependency resolution

Route lookup

Async runtime

Middleware execution

Feature compatibility

Supported features

Features in development

Migration guide

Switching from FastAPI

Known migration issues

When to use FastrAPI

Use FastrAPI when

Stick with FastAPI if

Future roadmap

Build docs developers (and LLMs) love

Get Started

Core Concepts

Guides

Advanced

​Quick comparison

​Performance benchmarks

​Throughput

FastrAPI

FastAPI (16 workers)

FastAPI (1 worker)

​Latency comparison

​Architectural differences

​Dependency resolution

​Route lookup

​Async runtime

​Middleware execution

​Feature compatibility

​Supported features

​Features in development

​Migration guide

​Switching from FastAPI

​Known migration issues

​When to use FastrAPI

Use FastrAPI when

Stick with FastAPI if

​Future roadmap

Build docs developers (and LLMs) love

Quick comparison

Performance benchmarks

Throughput

Latency comparison

Architectural differences

Dependency resolution

Route lookup

Async runtime

Middleware execution

Feature compatibility

Supported features

Features in development

Migration guide

Switching from FastAPI

Known migration issues

When to use FastrAPI

Future roadmap