Case Study
I Ran Refactron on FastAPI. Here's What It Found.
FastAPI is the youngest codebase in this series. Sebastián Ramírez released the first version in 2018 — which makes it seven years old, modern by Python standards, and built from the start with type hints, async support, and a clean architecture in mind.
It's also the fastest-growing Python web framework of the last three years. Which makes it an interesting contrast to Django and Requests. We're not looking at accumulated legacy complexity here. We're looking at what complexity looks like in a well-designed, actively maintained modern codebase.
Setup
git clone https://github.com/tiangolo/fastapi cd fastapi pip install refactron refactron analyze .
Ran in under 12 seconds.
What it found
The headline finding: FastAPI is genuinely clean. The type annotations are consistent, the module boundaries are clear, and the test coverage is solid. This is what well-maintained modern Python looks like and the analysis reflects it.
That said, a few things surfaced.
Complexity in the routing layer. fastapi/routing.py is doing a lot of work — parameter resolution, dependency injection, response model handling, exception routing. Each feature added to FastAPI over the years has left a trace here. The core routing functions have complexity scores that are elevated but not alarming. This is a known architectural tradeoff in framework design: the layer that coordinates everything else will always carry more complexity than the layers it coordinates.
Deep conditional nesting in parameter handling. The code that resolves incoming request parameters into Python function arguments has several layers of nested conditionals. Again, this is inherent to what the code is doing — handling every combination of path params, query params, body params, headers, and cookies requires branching. Refactron surfaces it as a complexity signal. Whether it's worth addressing is a judgment call for the maintainers.
A small number of long functions in the dependency injection system. Functions that handle dependency resolution end up being long because the logic is genuinely complex. These aren't candidates for automated decomposition — they're candidates for careful human refactoring with thorough test coverage, which FastAPI already has.
The autofix run
refactron autofix . --verify --dry-run
Fewer actionable suggestions here than in the Requests run. FastAPI's codebase is younger and has had more consistent maintenance attention — the low-hanging fruit has already been addressed.
The suggestions Refactron was confident proposing: a few unused imports in test utilities, one redundant variable assignment in an internal helper. Small, safe, uncontroversial.
For everything structural it flagged and stopped. The routing and dependency injection code is too central to FastAPI's behavior to touch without deep context. The right call.
What the output looks like
✓ Analyzing fastapi/ Files analyzed: 44 Issues found: 6 MEDIUM (3): High cyclomatic complexity routing.py:412 — score: 13 routing.py:218 — score: 11 dependencies/utils.py:89 — score: 10 LOW (3): Unused imports tests/test_dependency_overrides.py:4 tests/_test_tutorial/test_first_steps.py:2
Six issues in a well-maintained 44-file codebase. That's a meaningful baseline.
What this series is showing
Three runs in — Django, Requests, FastAPI — a pattern is emerging.
Well-maintained open-source Python codebases accumulate complexity in two predictable places: integration layers (the code that coordinates everything else) and test files (which get less maintenance attention than production code). Security issues, import problems, and dead code are largely absent because the maintainer community catches them.
The implication for internal codebases is straightforward. If a widely-scrutinised open-source library has six issues after years of active maintenance, a three-year-old internal service with one or two maintainers and no external review will have considerably more — concentrated in exactly the same places, with fewer eyes to catch them.
Try it
pip install refactron refactron analyze .
Next in this series: Flask — the oldest of the modern Python web frameworks, and probably the most interesting findings yet.