For Django developers

Visualize your Django architecture — the calls, not just the models

The standard advice for understanding a big Django codebase is "start at urls.py and trace each view by hand," or run graph_models — which draws the data schema only. Neither shows you what actually happens on a request. The call graph does.

urls → views → services → models no code executed Django not required

Every command below runs against a Django-shaped fixture that ships in the repo (examples/scenarios/django_shop — plain Python with the classic urls/views/services/models layering, because pure AST analysis doesn't need Django installed). The output is verbatim; run it yourself and get the same result.

1

One command → the whole request topology

A single self-contained HTML file: every function is a node, every call is an edge with a file:line, layers roll up to module view for the 10,000-ft picture.

$ pip install py-code-visualizer $ py-code-visualizer visualize examples/scenarios/django_shop -o shop.html
Built graph with 18 functions and 19 calls Interactive HTML visualization saved to shop.html

The canonical stats for this fixture: 18 functions, 19 calls, 0 cycles, 0 ambiguous edges — and the HTML is one self-contained file (zero network requests). Open it and click checkout_view — the inspector shows its exact location, callers, and callees, each one clickable. New team member? They can walk dispatch → checkout_view → OrderService.checkout → Order.create in a minute instead of grepping for a day.

2

What does touching checkout actually reach?

Before you refactor a service, get the blast radius — through every layer, not just the file you're in.

$ py-code-visualizer impact checkout examples/scenarios/django_shop
Impact analysis for: services.OrderService.checkout ⚠️ Touching `checkout` affects **2** transitive caller(s) across **4** module(s). Direct callers (1): ← views.checkout_view Direct callees (4): → models.Cart.for_user → models.Cart.subtotal → models.Order.create → services.OrderService._notify Modules affected: models, services, urls, views

Note what resolved there: cart = Cart.for_user(user) then cart.subtotal() — variable-type tracking through a classmethod constructor, statically. That's the accuracy an LLM can't give you, and every edge clicks through to its line.

3

Keep it alive in CI

Architecture docs rot. A deterministic diagram doesn't — CI regenerates it and commits only when the structure really changed.

$ py-code-visualizer init --with readme,review # opt-in: pick only what you want

That's a self-healing README diagram plus an automatic PR comment showing each change's blast radius — the review workflow.

vs. graph_models: django-extensions' graph_models is great at what it documents — a diagram of your model classes and relations. It doesn't show call flow: which view hits which service, what a request actually executes. Use both: graph_models for the schema, py-code-visualizer for the behavior — with provenance on every arrow.

Fixture: examples/scenarios/django_shop. Output shown verbatim. Works the same on real Django apps of any size — a measured 98,669-line project maps in ~4.9 s.

← All use cases