Graphtia documentation · workflow

From code to APIs and database schemas

Inspect API handlers, OpenAPI schemas, SQL declarations and supported code-to-table links before changing a service or database contract.

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.

Follow a real graph in Explorer

This native view follows the GET handler in the local order-flow example. It brings the API declaration, function calls, database operations and declared tables into the same graph. Read each connection by its label and evidence strength.

Explorer graph for GET in order-flow, with the API declaration, function calls, SELECT operations, orders and customers tables, and a Partial-view notice. — Real Explorer view of the order-flow example at depth 1: 10 nodes and 11 relationships. The graph retains Partial and unresolved-call indicators; SQL table matches are possible relationships, not evidence that a request or database query ran.

The GET handler calls readOrders and readCustomers. Their SELECT sites and the tables public.orders and public.customers are visible beside the SQL declaration. The next/server reference has an unresolved call; the Partial notice means relationships can exist outside this view.

Select a relationship to inspect its evidence and source location. A possible table match remains an inference, even when the source index is current. Explorer does not call the endpoint or execute the query.

An illustrative overview

Follow the evidence across a boundary

Illustrative static analysis: inspect an API candidate, its possible handler and a literal database query against a declared table. A matching name or route alone does not establish a runtime connection.

Source callCode location

API candidateMethod + path

Handler candidateInspect its source

Database queryLiteral access evidence

Declared tableSQL source

Related checksReview candidates

Candidate relationships need source review. This illustrates static evidence, not a running request.

Find the API entry point

Browse supported HTTP and gRPC consumer and provider declarations. Inspect the owning symbol and source location, then follow the supported calls, references and dependencies around that handler.

Read the contract beside the implementation

OpenAPI 3.0 and 3.1 JSON/YAML sources provide operation details and a bounded nested schema view with local references. Handler candidates retain their scope and ambiguity. A narrow supported Next.js declaration association can be established when its configuration and boundary evidence agree; this is not a universal runtime conformance check.

Explorer OpenAPI view for GET /orders showing a declared 200 response, a local schema reference, and orders and featured properties. — The GET /orders declaration shows its 200 application/json response, a local schema reference, and required orders versus optional featured properties. It is source contract evidence; no endpoint is called and no matching implementation is proved.

Connect supported database sites to declared tables

Inspect supported TypeScript/JavaScript driver receivers and literal or prepared SQL, plus supported Django and SQLAlchemy declarations. Code-to-table results include evidence strength and site diagnostics so unresolved receiver provenance or partial SQL remains visible.

Explorer highlights a possible Reads table link from a SELECT operation to public.orders; the Evidence panel labels it inferred and points to repositories/orders.ts line 7. — Selecting the SQL relationship highlights Possible: Reads table. The Evidence panel preserves Inferred evidence and points to repositories/orders.ts, line 7. The source location supports investigating this match; it does not confirm a live database query.

In the selected relationship above, the query is SELECT id, customer_id, total from the orders source. The possible match leads to the declared public.orders table. Open relation evidence to inspect the source; use the source and target actions to examine either endpoint. Keep Inferred evidence distinct from a confirmed static relationship.

Inspect the declared schema

PostgreSQL, SQLite and MySQL declarations can expose tables, columns, keys, supported indexes, checks and source-ranged schema inventory. Supported CREATE/ALTER composition and comparisons with supplied DDL can help review a migration plan. Explorer does not connect to a live database or apply the migration.

Explorer SQL view with PostgreSQL explicitly selected, public.orders, three fields, one index, two changes and Partial analysis notices. — With PostgreSQL explicitly selected, Explorer shows public.orders with three declared fields, one index and two change declarations. The visible Related declarations section preserves possible CREATE/ALTER matches and Partial analysis notices; execution and the resulting database schema remain unknown.

Review the change in both directions

For an API or table change, investigate supported callers and consumers, related source candidates and possible tests. Inspect each layer's source and revision; validate behavior with your normal build, test and database workflows.

A practical investigation

Start with an API operation or declared SQL table and inspect its source location.
Open the relevant handler or database access site. Confirm the exact relationship evidence, dialect and current indexed revision.
Follow direct dependencies and consumers around that site. Treat a missing link as an unanswered question until coverage is checked.
Use the result to prepare code, contract and database validation through your normal tools.

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.

Inspect the combined map

Follow the same illustrative relationships from either starting point: API endpoint and handler or SQL declarations and foreign key. The map retains edge direction and separates evidence strength from partial coverage.