Graphtia documentation · workflow

Cross-language code analysis

Explore supported relationships across TypeScript, Rust, HTTP, gRPC and task boundaries with source evidence, revision context and visible uncertainty.

Investigate how supported source code connects across language boundaries, API declarations and declared SQL tables. Keep the source location, indexed revision and strength of each relationship in view as you assess a change.

A migration or refactor can cross more than a function boundary. Explorer brings those different forms of evidence into one local workspace for people and their coding agents.

Keep each side of the boundary in view

An index can retain declarations in different languages. Supported boundary evidence can connect a consumer to a provider candidate; missing or ambiguous evidence must remain unresolved.

Consumer sourceOne language

Shared boundaryAPI or contract evidence

Provider candidateAnother language

Source scopeProject + revision

Inspect the matchScope and uncertainty

Unresolved targetKeep the gap visible

A boundary candidate is not proof of runtime traffic. Unsupported or ambiguous targets remain visible.

Start at a boundary, keep the evidence

Explorer distinguishes consumers, exposed providers and established bindings. This preserves the difference between a normal function call and a connection through an API, IPC command or task queue.

TypeScript and Rust through Tauri IPC

Recognized JavaScript or TypeScript invoke sites can be associated with supported Rust command declarations and registrations. Inspect the consumer, registration and provider together before changing a command. Dynamic names, duplicate candidates or missing registrations remain explicit gaps.

HTTP across supported stacks

Concrete methods and paths, compatible application scope and a unique recognized provider can establish a static HTTP boundary. Similar URLs alone do not prove a connection. Use the API catalog and source evidence to inspect the supported candidates.

gRPC and asynchronous tasks

Recognized generated Go, Java and .NET patterns contribute gRPC boundary identities. Supported Python Celery producers and consumers contribute asynchronous task identities. These are bounded adapters; they do not prove broker delivery, arbitrary protocol compatibility or support for every generated binding.

Inspect the path and its limits

Use neighborhood, path and impact queries within the authorized project and published revision. Preserve unresolved or ambiguous results and the view's scope. Cross-language relationships do not imply automatic federation of unrelated workspaces.

The supported boundary families are Tauri IPC, HTTP, generated-binding gRPC and Python Celery tasks. They do not provide arbitrary foreign-function bridges such as JNI, P/Invoke or cgo. A source-level binding is not runtime message delivery or proof of wire compatibility.

A practical investigation

Choose the caller, route, command or task you intend to change in one indexed workspace.
Inspect its source identity and the candidate provider. Check method/path, registration or service identity as appropriate.
Follow supported relationships in a bounded graph or through an authorized coding agent. Keep any ambiguous segment visible.
Record direct consumers, related-test candidates and the runtime checks your team will perform.

A chain of evidence

Consumer code → API or IPC boundary → handler → database access site → declared SQL table. This is an illustrative investigation path. Each segment needs its own supported evidence; a missing or ambiguous segment is a gap, not a connection to infer.

Scope to retain with the answer

This is source-based investigation. Each supported link must be checked independently; a diagram is not a runtime request trace or proof that a deployed database matches the declarations.