archview

How it works

The analysis pipeline, from source to graph.

archview is static analysis, not a runtime tracer. At startup it reads your source and derives the graph in one pass:

source → go/packages (AST + types) → CHA call graph
       → classify layers (folder/naming) → extract routes (per framework)
       → graph model → /graph (embedded SVG renderer)

1. Load packages

It loads your module with golang.org/x/tools/go/packages (syntax + type info), then builds the SSA form with ssautil. Only your project's own packages are kept; standard library and dependencies are excluded from the node set.

2. Build the call graph

A CHA (Class Hierarchy Analysis) call graph resolves calls — including calls through interfaces — to their implementing methods. For the common case of one implementation per interface (a service interface with a single impl), this is exact, which is why controller → service → repository edges appear even when the layers are wired through interfaces.

3. Classify layers

Each function's import path is mapped to a layer (controller / service / repository) by naming convention, and to a module (the bounded-context name).

4. Extract routes

A per-framework extractor walks the syntax for route registrations (r.GET(...), mux.HandleFunc(...)) and resolves each to the handler function it points at.

5. Assemble the graph

The builder keeps endpoints and layered functions, derives the call edges between them (collapsing through unclassified helper functions so a thin wrapper doesn't break a controller → service link), prunes isolated nodes, and attaches each function's file:line:col as an editor deep link.

Because the graph is computed once at New(), it is a snapshot. Restart (or re-call New) to pick up source changes. Live reload is on the roadmap.

On this page