Does it understand async FastAPI handlers and decorators?

Yes. Async functions are collected and tagged, decorator names are recorded as metadata, and even decorator closures (e.g. wrap functions inside a route decorator) appear with correct qualified names like deps.get. .wrap — because collection is a real recursive AST visitor, not a regex.

Does FastAPI need to be installed for the analysis?

No. Analysis is pure AST parsing — nothing is imported or executed. It maps any FastAPI-style codebase without its dependencies, which also makes it safe and fast in CI.

Can it detect circular dependencies in a FastAPI service?

Yes, at the call-graph level (stricter than import linters). 'check --fail-on-cycles' exits non-zero on any cycle, and 'diff --fail-on-new-cycles' fails a PR that introduces one.

FastAPI Call Graph — See Every Route's Real Blast Radius

Commands below run against a FastAPI-shaped fixture in the repo (examples/scenarios/fastapi_svc — decorated async handlers → services → repositories, in plain Python since pure AST analysis needs no framework installed). Output is verbatim.

The blast radius of the order flow

$ py-code-visualizer impact place examples/scenarios/fastapi_svc

Impact analysis for: services.OrderFlow.place ⚠️ Touching `place` affects **1** transitive caller(s) across **3** module(s). Direct callers (1): ← app.create_order Direct callees (3): → repos.InventoryRepo.reserve → repos.OrderRepo.insert → services.OrderFlow._audit Modules affected: app, repos, services

One glance: change place() and you touch the POST /orders handler above you and two repositories below you. For a handler itself, the same command shows its full downstream execution path — the thing new teammates spend days reconstructing by hand.

Never ship a dependency cycle

Service ↔ repo cycles creep into API codebases quietly. Gate them at the call-graph level — stricter than an import linter, because a call edge is a real runtime dependency.

$ py-code-visualizer check examples/scenarios/fastapi_svc --fail-on-cycles

✅ Architecture check passed: no rule or cycle violations. $ echo $? 0 # clean — and it exits 1 the day a cycle appears

Hand your AI agent the verified slice

Asking an agent to modify the order flow? Give it facts, not a repo dump. Note the closures — deps.post.<locals>.wrap — collected with correct qualified names, because this is a real AST visitor, not a regex.

$ py-code-visualizer context examples/scenarios/fastapi_svc --focus OrderFlow.place

# Context Pack — fastapi_svc - Focus: `services.OrderFlow.place` - Included functions: 18 ## Functions - `app.create_order(payload)` — examples/scenarios/fastapi_svc/app.py:13 - `deps.post.<locals>.wrap(fn)` — examples/scenarios/fastapi_svc/deps.py:12 - `repos.InventoryRepo.reserve(self, sku)` — examples/scenarios/fastapi_svc/repos.py:22 … ## Verified calls (caller → callee · confidence · provenance) - `app.create_order` → `services.OrderFlow.place` · resolved · …/app.py:15 - `services.OrderFlow.place` → `repos.InventoryRepo.reserve` · resolved · …/services.py:17 - `services.OrderFlow.place` → `repos.OrderRepo.insert` · resolved · …/services.py:18 …

Every fact carries provenance; ambiguous calls would be flagged, never guessed. See the full agent-context walkthrough — on a 100k-line project the pack is 97% smaller than feeding the source.

What you got. Route-to-repository visibility with provenance on every edge, a cycle gate that runs in CI without installing your app's dependencies, and task-scoped verified context for the AI tools already editing your service. Async, decorators, and closures handled correctly — statically.

Fixture: examples/scenarios/fastapi_svc. Output shown verbatim except lists trimmed with … and repeated path prefixes shortened to …/ for width (run it to see all 18 functions with full paths and GitHub links).

← All use cases