Falcon REST Framework — Core Concepts

What Falcon is

Falcon is a minimalist WSGI and ASGI framework for building REST APIs and microservices in Python. Created by Kurt Griffiths, it’s designed around the philosophy that frameworks should get out of the way and let your code run fast.

Where Flask and Django process requests through layers of abstraction, Falcon uses a lean request pipeline with minimal overhead per request. In benchmarks, Falcon consistently outperforms most Python frameworks on raw throughput.

Resource-based design

Falcon’s fundamental design pattern is resource-oriented rather than route-oriented. Instead of decorating functions with URL patterns, you create resource classes with methods for each HTTP verb:

class UserResource:
    def on_get(self, req, resp, user_id):
        user = db.get_user(user_id)
        resp.media = {"id": user.id, "name": user.name}
    
    def on_put(self, req, resp, user_id):
        data = req.media
        db.update_user(user_id, data)
        resp.status = "200 OK"
    
    def on_delete(self, req, resp, user_id):
        db.delete_user(user_id)
        resp.status = "204 No Content"

This maps naturally to REST semantics. A “resource” in REST is something identified by a URL — a user, an order, a document. Having a class per resource with methods per HTTP verb makes the mapping explicit.

The request pipeline

Falcon processes requests through a minimal pipeline:

Client → Middleware → Router → Responder (on_get/on_post/...) → Middleware → Client

Each component does one thing:

Middleware handles cross-cutting concerns (authentication, logging, CORS). Middleware classes implement process_request, process_resource, and process_response methods.

Router matches the URL to a resource class. Falcon’s router is compiled at startup for fast matching.

Responders are the methods on your resource class (on_get, on_post, etc.) that handle the actual business logic.

There’s no template engine, no ORM, no session management, no form handling. Falcon provides the HTTP plumbing and lets you choose your own tools for everything else.

WSGI and ASGI support

Falcon supports both synchronous (WSGI) and asynchronous (ASGI) modes:

WSGI (traditional): Use falcon.App() and deploy with gunicorn or waitress. Handlers are regular functions.

ASGI (async): Use falcon.asgi.App() and deploy with uvicorn. Handlers use async def. This mode supports WebSockets and Server-Sent Events alongside regular HTTP.

The API is nearly identical between modes — switching from WSGI to ASGI mostly means adding async to your handler methods and swapping the App class.

Middleware model

Falcon’s middleware is explicit and ordered:

class AuthMiddleware:
    def process_request(self, req, resp):
        token = req.get_header("Authorization")
        if not verify(token):
            raise falcon.HTTPUnauthorized(description="Invalid token")
    
    def process_response(self, req, resp, resource, req_succeeded):
        resp.set_header("X-Request-ID", req.context.request_id)

process_request runs before routing. process_resource runs after routing but before the responder (it receives the matched resource object). process_response runs after the responder.

This three-phase model gives you precise control over when your middleware logic executes.

How Falcon compares

vs. Flask: Flask is function-decorated and template-friendly. Falcon is class-based and API-focused. Flask has a massive extension ecosystem; Falcon has intentionally fewer. For APIs where performance matters, Falcon wins. For web apps with HTML rendering, Flask wins.

vs. FastAPI: FastAPI provides automatic data validation, dependency injection, and OpenAPI docs. Falcon is lower-level and faster but requires you to validate inputs manually. FastAPI is better for developer productivity; Falcon is better for raw performance.

vs. Django REST Framework: DRF is built on Django and inherits its ORM, auth, and admin. It’s excellent for CRUD APIs that need these features. Falcon is for services where Django’s overhead isn’t justified.

Performance philosophy

Falcon’s speed comes from deliberate design choices:

• No request body parsing by default — Falcon only parses the body when you access req.media
• No response serialization by default — you control exactly what gets serialized and when
• Minimal object creation — fewer temporary objects per request means less garbage collection
• Compiled routing — URL matching is optimized at startup, not per-request

These micro-optimizations compound at scale. When handling 10,000 requests per second, saving 50 microseconds per request saves half a second of CPU time every second.

Common misconception

Developers sometimes think Falcon is too low-level to be productive. But its simplicity is an advantage for API development — there’s less magic to debug, fewer abstractions to learn, and the code reads as straightforward Python. What you write is very close to what runs.

The one thing to remember: Falcon’s resource-oriented design maps directly to REST semantics while its minimal overhead makes it one of the fastest Python frameworks — choose it when your API’s performance and clarity matter more than framework conveniences.