Skip to content

Code graph

A three-dimensional map of the Skywire source: every function, method, type and file as a node, every call and reference as an edge. It is a way to see the shape of the codebase — which packages are dense, what the hubs are, and which files nothing reaches.

  • Open the graph

    Drag to orbit, scroll to zoom, click a node to focus it. Filter by node type or folder in the left panel; the Display controls dim the links and the glow, which helps when a dense region washes out to white.

What it shows

The whole graph: 56,390 nodes and 366,526 edges — every function, method, variable and section the indexer found, and every call and reference between them. 36 MB as a file, about 4.6 MB over the wire once the server compresses it, so it takes a moment to arrive.

Colour is by node type — 15,690 functions, 14,791 variables, 10,876 methods, 4,143 sections — and the folder tree in the left panel carries the count for each directory, which is a reasonable answer on its own to "where is the code?". pkg/ holds 31,763 of them.

At this size the viewer's own contrast defaults render the graph as a white ball, which its Display panel warns about. The page ships lower values for the edge, glow and bloom strengths so the first view is legible; move the sliders and your choice is kept.

Nodes appearing as a loose halo away from the main mass are files the indexer could not fully parse: generated bundles, vendored JavaScript, and the Kotlin and SCSS that the Go-oriented analysis only sees as files.

How it is made

The graph comes from codebase-memory-mcp, which indexes a repository into a queryable graph and serves a viewer for it on localhost. Two properties make that viewer publishable as static files:

  • the layout is computed server-side — /api/layout returns every node with its coordinates already assigned, so the browser is only a renderer and there is no simulation to run;
  • a static host ignores the query string, so one file at api/layout.json answers every request the viewer makes for a layout, whatever parameters it appends. The extension is not decoration: it is what earns the file a compressible content type, and so a gzipped response.

So the snapshot is the upstream bundle plus the layout saved as a file. Three things about the bundle had to change: its absolute /api/ and /assets/ paths are made relative, because this is served from a subdirectory; the page supplies its own default query parameters, because opened without any the viewer asks the server to enumerate projects over a POST that no static host can answer and renders nothing at all; and it seeds the contrast settings described above.

scripts/graph-snapshot.sh does all of it:

# with codebase-memory-mcp running and this repository indexed
./scripts/graph-snapshot.sh              # the whole graph, 36 MB
NODES=5000 ./scripts/graph-snapshot.sh   # a lighter subset, ~2 MB

The indexer names a project after the path of the checkout it was run on, which would otherwise put somebody's home directory into every qualified name on this page. The script rewrites it to skywire and then greps the output to prove nothing local survived.

One consequence of the query-string trick: the NODES control and Refresh button in the viewer do nothing here. Every value they ask for is answered by the same file.

Caveats

  • It is a snapshot, regenerated by hand rather than on every commit. The indexer is a 294 MB binary, which is not something to run in CI.
  • 4.6 MB over the wire is a real download. It is the whole graph on purpose; regenerate with NODES= for something lighter.
  • The renderer is WebGL with a bloom pass, so it wants a GPU. On integrated graphics, turn the Bloom and Node glow sliders down further.

The viewer's per-node links point at github.com/skycoin/skywire on develop, which is written into the snapshot rather than taken from whatever checkout it was generated on. Pass REPO_URL and REPO_BRANCH to the script to point them somewhere else.