Skip to main content

Graph Explorer

This page introduces the main controls in the Graph Explorer panel.

Read this page if the app is already running and you want to understand what the explorer controls are for before diving into deeper architecture or protocol details.

DependencyAtlas builds the main graph from source-first static analysis. It is not a runtime execution trace. Optional JET results appear as separate on-demand views rather than changing the main graph.

Graph Explorer

Modules: 4Files: 8Methods: 31Edges: 66
includedefineimportcall_exactcall_inferredcall_possiblecall_dynamic

Summary counters​

The four summary counters at the top show how many modules, files, methods, and edges are currently in the loaded graph snapshot.

They are useful as a quick sanity check before you start filtering:

  • Modules gives the current module count in the snapshot
  • Files gives the current file count
  • Methods gives the current method count
  • Edges gives the current edge count

These numbers describe the loaded graph data, not only the nodes currently visible after every filter.

Layer​

DependencyAtlas exposes three graph layers:

  • method
  • file
  • module

The Layer selector switches between them. Each layer answers a different question.

Method view​

Use method view when you want the most detailed call and define relationships.

This is usually the best place to:

  • inspect concrete call chains
  • examine overloads
  • study external calls

File view​

Use file view when you want a structural overview of how source files relate to each other.

This is often the best entry point for understanding project shape without reading every method-level edge.

Module view​

Use module view when you want the highest-level architectural picture.

This is useful for:

  • package-level or subsystem-level understanding
  • explaining a codebase to someone else
  • finding broad boundaries before zooming back in

Search filters the graph by file path, node label, fully qualified name, or kind.

Use it when you already know what you want to inspect and want to reduce the canvas quickly.

Files to include / exclude​

Files to include and Files to exclude let you narrow the working set by path pattern before reading the graph in detail.

Use them when you want to:

  • focus on one subsystem such as src/runtime/**
  • hide noisy areas such as test/** or docs/**
  • keep the explorer readable on larger repositories

Layout​

Layout changes the broad graph direction used to place nodes.

In the current UI, the main presets are:

  • left to right
  • top to bottom

Use left to right when you want call flow to read horizontally. Use top to bottom when you want a more compact vertical stack.

Layout Engine​

Layout Engine changes the layout engine variant behind the selected layout.

The current options are:

  • Sugiyama lite
  • ELK layered crossing min

Choose Sugiyama lite when you want fast iteration. Choose ELK layered crossing min when you want a cleaner layered result and can tolerate more waiting.

ELK Edge Routing​

ELK Edge Routing only applies when the layout engine is ELK layered crossing min.

The current options are:

  • orthogonal
  • polyline
  • splines

Use it when you want to change how ELK itself routes edges through the layered layout.

Edge Path​

Edge Path changes how edges are drawn between nodes.

The current options are:

  • native ELK
  • rounded route
  • orthogonal
  • bezier
  • smoothstep
  • step

Some of these modes reuse ELK's routed path directly, while others draw the same graph through React Flow edge styles. This changes presentation only; it does not change the underlying graph data.

Reachability Direction​

Reachability Direction controls whether a reachability query follows:

  • callers
  • callees
  • both directions

Use callers when you want to know what can reach a node. Use callees when you want to know what a node can reach. Use both when you want a bounded neighborhood around the selected node.

Reachability Depth​

Reachability Depth sets how many steps away from the selected node the reachability query can expand.

A lower depth keeps the result focused. A higher depth shows more context, but can grow quickly in dense graphs.

Show Overloaded Functions​

Show Overloaded Functions reveals overloaded Base, Core, or stdlib generics that are relevant to the current graph.

This is useful when project methods extend shared generics and you want those overload sites to stay visible.

This toggle is mainly about overloaded external generics, not about collapsing project methods together. In practice that means:

  • project-defined overloads such as multiple meet(...) methods still appear as separate method nodes
  • overloaded external generics such as Statistics.mean or Logging.handle_message may appear as one external generic node with overload styling

So if two examples look different on the canvas, that is usually because one is showing project-owned method definitions while the other is showing an external generic that your project extends.

Show Base/Stdlib Calls​

Show Base/Stdlib Calls controls whether calls into Base and the Julia standard library remain visible.

Turn it on when you want more complete dependency context. Turn it off when you want to focus more narrowly on project-owned code.

Show External Package Calls​

Show External Package Calls controls whether calls into external packages remain visible in the graph.

This is especially useful when your project relies on package APIs and you want to see where those boundaries appear in the dependency story.

Edge kind filters​

The edge-kind chips let you enable or disable specific relationship kinds.

Typical examples include:

  • include
  • define
  • import
  • call_exact
  • call_inferred
  • call_possible
  • call_dynamic

Use these chips when the graph feels dense and you want to temporarily suppress one class of relationship without changing everything else.

Export controls​

The export buttons let you take the current graph state out of the UI:

  • Export to File
  • Export .drawio

These are useful for sharing, debugging, creating static examples, or continuing work in external diagram tools.

Reading the graph itself​

The sections above describe the controls in the Graph Explorer panel. The sections below explain how to interpret the graph shown on the canvas once those controls are applied.

Read nodes first​

At a high level, nodes represent entities in the current layer:

  • methods in method view
  • files in file view
  • modules in module view

Some nodes belong to your project, while others represent external code such as Base, stdlib APIs, or external packages.

External nodes are useful because they show where your project touches code outside your own repository.

Then read edges​

Edges express relationships such as:

  • include
  • import
  • define
  • call relationships such as call_inferred, call_possible, and call_dynamic

Not every edge means the same thing. Structural edges such as include and define are different from call evidence edges.

Overloads and piracy-like styling​

DependencyAtlas also highlights overload-related semantics.

The important categories are:

  • none: no overload signal
  • safe: overload with project-type evidence
  • piracy_like: overload-like signal without project-type evidence

As a user-facing reading rule:

  • safe overloads usually mean "this extends behavior in a project-owned way"
  • piracy-like signals should make you slow down and inspect the definition more carefully

This is especially useful when project methods interact with Base, stdlib generics, or external package generics.

There is also an important display distinction:

  • project-owned overloads stay split into separate method nodes, because each definition is part of your codebase
  • overloaded external generics can be shown as one external generic node with overload styling, because the graph is emphasizing the shared external API surface rather than duplicating every external generic node

That is why a project function family and an overloaded stdlib generic do not always look the same even when both involve multiple method definitions.

Why external nodes matter​

External nodes are not noise. They help answer questions like:

  • where does this project call into Base
  • which stdlib APIs are on the path
  • which external package symbols show up in the dependency story

Without them, the graph would often hide exactly the boundaries you want to inspect.

A good first reading workflow​

If a graph feels dense, use this order:

  1. start broad in file or module
  2. identify one region or node that matters
  3. switch to method
  4. inspect node details and source snippets
  5. only then worry about more ambiguous evidence kinds

That keeps the graph useful instead of overwhelming.