Falcon: a no-magic ASGI and WSGI framework for Python APIs

The problem Falcon is aimed at, and the developers it assumes

Falcon targets HTTP APIs and microservices rather than server-rendered sites. The README frames the choice as a subtraction: other frameworks, it says, weigh you down with dependencies and unnecessary abstractions, and Falcon cuts to the chase with a design that embraces HTTP and the REST architectural style. That is a statement about who the framework is for. It assumes you already know what a status code, a content type and a query string are, and that you would rather write them explicitly than have a framework infer them.

The README lists the intended capabilities plainly: ASGI, WSGI and WebSocket support, native asyncio, centralized RESTful routing, middleware components and hooks, and idiomatic HTTP error responses. The pyproject.toml classifiers describe the project as Production/Stable and list CPython and PyPy, with Python 3.9 as the floor. The dependency list is empty, so installing Falcon does not pull a transitive tree into your lock file. For a service that has to be audited, that is the point: fewer packages to track.

The audience is narrower than a general web framework's. If your application is mostly HTML forms, sessions and templates, the README offers nothing for you. If your application is a JSON surface in front of a database or a queue, and you want to see every header that leaves the process, Falcon is built for that case.

Routing, responders and the absence of magic globals

The central mechanism is a resource class whose methods map to HTTP verbs. You create an application object, call add_route with a URL template, and Falcon dispatches the incoming request to a method named after the verb, such as on_get or on_post. The README calls this simple API modeling through centralized RESTful routing, and it means the routing table is readable in one place instead of being scattered across decorators.

State management does not rely on magic globals. The README states this as a feature, and it has a practical consequence: a request object and a response object are passed into the responder, so a function that handles a request can be read without knowing what the framework has stored somewhere else. The same design makes the testing helpers usable, since the README advertises WSGI/ASGI helpers and mocks for snappy testing.

Potentially surprising behaviour is opt-in. The README says that automatic request body parsing is well documented and disabled by default. That is a real trade-off. You will write more code to read a JSON body than you would in a framework that parses it for you, and in exchange nothing is parsed behind your back when a client sends an unexpected content type. Falcon also ships middleware components and hooks for request processing that would otherwise be repeated in every responder.

One architectural detail is worth flagging. The setup.py in the repository shows that Cython compilation is applied to falcon.cyutil, with the main falcon package and the media, routing and util modules commented out. A comment in that file notes that on recent CPython versions, cythonizing pure Python code is a de-optimization. The README still describes Cython as an extra speed boost when available, so the two statements sit at different points in time; the build file is the more specific one.

Installing Falcon and serving a first route

Falcon is distributed on PyPI. The README points to the PyPI package badge and the documentation at falcon.readthedocs.io, and the project requires Python 3.9 or newer. Install it into your environment with pip.

pip install falcon

Falcon is not a server, so you also need a WSGI or ASGI server to run the application. The repository ships example applications under examples/, including things.py for WSGI and things_asgi.py for ASGI. Those files are the reference for the shape of a Falcon application: the documentation describes a resource class whose methods are named after HTTP verbs, an application object created from the framework, and a route registered against a URL template. Read examples/things.py before writing your own resource.

The README also lists examples/things_advanced.py and the ASGI equivalents, which are the better starting point once you need more than one route, because they show how the same resource pattern scales across verbs. For a first real use, run one of the bundled examples rather than a hand-written file. The examples directory includes a requirements.txt, and the ASGI tutorial lives under examples/ws_tutorial/. Because the README does not print a source listing for the examples, the file in the repository is the authoritative version of the code.

Where Falcon is the wrong tool

The README is candid about the design, and the same candour identifies the failure modes. Falcon leaves decisions and implementation details to the API developer. That is freedom if you have opinions, and a gap if you do not. There is no bundled ORM, no admin site, no template engine and no form validation layer. A team that wants a project scaffold with those pieces included will spend its first week assembling them from other packages.

Automatic request body parsing is disabled by default. A developer arriving from a framework that deserializes JSON on the way in will find that a POST handler does not receive a parsed dictionary until they ask for one through the media attribute or a media handler. The README presents this as a deliberate choice to avoid surprising behaviour. The cost is real: every new endpoint that accepts a body needs that step written out.

The dependency-free policy cuts both ways. Because Falcon has no dependencies outside the standard library, it cannot hand you a database driver or a schema validator, and its own release cycle is decoupled from the libraries you pick. You own the integration. If your API is small and your team is small, that ownership is a maintenance load rather than a benefit.

Finally, Falcon is a framework, not a deployment. The README says Falcon apps work with any WSGI or ASGI server. Choosing Falcon does not answer how the process is supervised, how TLS terminates, or how requests are routed across instances. Those remain yours.

Falcon compared with a batteries-included framework

The natural alternative is a general Python web framework in the Django or Flask family. The README names both directly when it claims Falcon turns around requests significantly faster than other popular Python frameworks like Django and Flask. The difference is not only speed. It is what arrives in the box.

Django ships an ORM, a migration system, an admin interface, authentication and a template language. A Falcon application ships none of these. If your project needs a content management surface for non-developers, Django's admin answers that on day one, and Falcon does not answer it at all. If your project is a service that returns JSON to another service, the admin interface is dead weight, and the ORM is a layer you may not want between your handlers and your queries.

Flask sits closer to Falcon in size, and the README's comparison still applies: Flask is described as a general framework that Falcon complements rather than replaces. The practical difference is in routing and state. Falcon's routing is centralized through add_route with resource classes, and the README states there is no reliance on magic globals for routing and state management. A developer choosing between them should look at how each one represents a resource and decide which shape matches the team's reading habits.

The README also points to Falcon add-ons and complementary packages on the project wiki, which is where serialization, validation and database integration live. That is the intended pattern: Falcon supplies the HTTP layer, and the community supplies the rest.

Maintenance, versioning and the Apache-2.0 licence

Falcon is licensed under Apache-2.0, and the pyproject.toml declares license = "Apache-2.0" with license-files = ["LICENSE"]. Apache-2.0 is a permissive licence that includes an explicit patent grant, which matters to organisations that review dependency licences before adoption. This is not legal advice; the LICENSE file in the repository is the authoritative text.

The repository is not archived, and the last push was on 2026-09-21. The most recent releases listed are 4.3.1 on 2026-06-16 and 4.3.0 on 2026-06-15, with a release candidate on 2026-06-12. The README states that breaking changes are fully documented and introduced only with a major version increment, in the spirit of SemVer. For an upgrade plan, that means a minor or patch bump should not require code changes, and a major bump is where to look.

The upgrade cost is mostly the cost of your own integrations. Because Falcon has no dependencies, upgrading Falcon does not force a coordinated upgrade of an ORM or a validation library. The reverse is also true: a breaking change in one of those libraries is your problem, not Falcon's release schedule. The CHANGES.rst file at the repository root is where the project records what moved between versions, and RELEASE.md documents the release process. Reading CHANGES.rst before a major bump is the concrete step that replaces guesswork.

Editorial conclusion

Adopt Falcon if you are building a JSON or REST API where request and response handling should stay visible, and your team is comfortable choosing its own validation and serialization libraries. Do not adopt it if you expect an ORM, an admin interface, or automatic request body parsing, since the README states that surprising behaviours such as automatic body parsing are disabled by default. Before committing, read the resource class in examples/things.py and the ASGI variant in examples/things_advanced_asgi.py, then check whether your deployment target can run the WSGI or ASGI server you already use, because Falcon itself is not a server.

Frequently asked questions

Official sources

1. falconry/falcon on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases