Graphtia documentation · reference
Go HTTP and gRPC framework analysis
See how Explorer recognizes Go net/http, Gin, Echo, Fiber, gRPC Go, which source relationships it exposes, and what remains outside static coverage.
These adapters add framework structure to the language index. The sections below separate detection, supported relationships, required source context and limits.
Explore an example: net/http · Gin · Echo · Fiber · gRPC for Go
Go net/http
Trace source-declared HTTP routes to accepted Go handlers, including direct DefaultServeMux registrations.
Where does this ServeMux registration point?
Evidence to inspect- Exact net/http import to HandleFunc registrationreceiver provenance
- HandleFunc registration to Declared /orders routeliteral path
- Declared /orders route to ordersHandler functionhandler binding
Connect a recognized net/http registration to its source-declared path and accepted Go handler. Classic patterns retain generic method evidence.
Computed paths, unproven receiver aliases and custom wrappers can remain unresolved. Import and registration evidence distinguish a supported route from an unrelated method with the same name.
How it is recognized
Exact net/http import; recognized package-level or statically owned ServeMux API.
Relationships you can inspect
Handle/HandleFunc registrations and handler bindings.
Classic patterns retain ANY; recognized method-bearing ServeMux patterns use method/path evidence when the source module declares Go 1.22 or newer.
Required source context
Accepted Go language facts, immutable source, exact imports and statically proven router/handler ownership; go.mod provides available version/project context.
Coverage limits
Declared Go version is a recognition prerequisite, not a tested-version promise.
Dynamic registration, computed prefixes, custom wrappers and middleware execution remain partial or unresolved.
Unproven receiver aliases or shadowed default-mux import aliases remain unresolved.
Gin
Connect Gin routes to their final handler and inspect static group prefixes and middleware registrations.
What route results from this group, and which handler is registered?
Evidence to inspect- Group /api to GET /api/ordersstatic prefix
- GET /api/orders to listOrders handlerfinal handler
- GET /api/orders to Registered auth middlewaremiddleware declaration
Inspect a literal group prefix, its route, final handler and middleware registration without treating the chain as an executed request.
Dynamic prefixes, custom wrappers and middleware execution are not inferred. Static group composition gives the declared route; middleware remains registration evidence.
How it is recognized
Exact github.com/gin-gonic/gin import and a proven router constructor/owner.
Relationships you can inspect
Recognized HTTP route methods and final-handler bindings.
Nested literal Group prefixes; router/group Use and preceding route arguments as middleware declarations.
Required source context
Accepted Go language facts, immutable source, exact imports and statically proven router/handler ownership; go.mod provides available version/project context.
Coverage limits
Dynamic registration, computed prefixes, custom wrappers and middleware execution remain partial or unresolved.
Middleware facts describe registration, not effective runtime behavior.
Echo
Inspect Echo route handlers, static nested groups and declared middleware in their source context.
Which handler and middleware belong to this grouped route?
Evidence to inspect- Group /admin to GET /admin/ordersliteral group prefix
- GET /admin/orders to adminOrders handlerhandler binding
- GET /admin/orders to Registered access middlewaremiddleware reference
Review a source-declared Echo group, effective literal path, handler and middleware references when reorganizing endpoints.
Runtime routing, computed prefixes and effective authorization are not established. Declared prefixes and references explain where the route comes from.
How it is recognized
Recognized exact imports are github.com/labstack/echo, github.com/labstack/echo/v4 and github.com/labstack/echo/v5, together with a proven echo.New() receiver. The unsuffixed import is not a claim that every version 3 release is supported, and it does not imply recognition of an /echo/v3 import.
Relationships you can inspect
Route method/path/handler declarations.
Static group prefix composition and router/group/route middleware references.
Required source context
Accepted Go language facts, immutable source, exact imports and statically proven router/handler ownership; go.mod provides available version/project context.
Coverage limits
Dynamic registration, computed prefixes, custom wrappers and middleware execution remain partial or unresolved.
Recognized module-path forms are not certification of every Echo release.
Fiber
Inspect Fiber route registrations, handler links, static groups and deduplicated middleware facts.
Which source registrations contribute to this endpoint?
Evidence to inspect- Group /shop to GET /shop/ordersstatic group prefix
- GET /shop/orders to ordersHandlerhandler binding
- GET /shop/orders to Declared Use middlewaremiddleware registration
Inspect a recognized Fiber group, its route handler and declared middleware while keeping runtime mount behavior separate.
Dynamic mounting, wrappers and middleware execution remain outside the static result. Recognized Group and Use forms add source relationships without simulating Fiber.
Logo credits
Fiber logo by Vic Shóstak, CC BY-SA 4.0. Original artwork, displayed at a smaller size without alteration.
How it is recognized
Recognized exact imports are github.com/gofiber/fiber, github.com/gofiber/fiber/v2 and github.com/gofiber/fiber/v3, together with a proven fiber.New() receiver. Matching a package path identifies supported source patterns; it does not certify every release under that path.
Relationships you can inspect
Recognized route method/path and handler declarations.
Static Group and Use relationships, including route middleware.
Required source context
Accepted Go language facts, immutable source, exact imports and statically proven router/handler ownership; go.mod provides available version/project context.
Coverage limits
Dynamic registration, computed prefixes, custom wrappers and middleware execution remain partial or unresolved.
Runtime mount behavior and wrapper APIs are not inferred; recognized import forms do not establish all-version compatibility.
gRPC Go
Follow supported generated service/RPC identities through Go implementations, server registration and proven client uses.
Which implementation is registered for this generated service?
Evidence to inspect- Generated Orders service identity to RegisterOrdersServer callservice identity
- RegisterOrdersServer call to OrdersServer implementationregistration evidence
- OrdersServer implementation to GetOrder methodaccepted implementation member
Follow recognized generated service identity, registration and implementation facts before changing an RPC method.
Standalone Proto parsing, message conformance, interceptors and observed delivery are not claimed. The diagram shows supported generated-binding and registration evidence, not a network request.
How it is recognized
Exact google.golang.org/grpc import plus recognized generated bindings and registration/client forms.
Relationships you can inspect
Proven server variables, Register*Server declarations and accepted implementation facts.
Generated service/client method identities produce scoped gRPC provider/consumer candidates.
Required source context
Generated binding source and accepted Go facts must be available; exact service, RPC and application scope are required for correlation.
Coverage limits
Standalone .proto schema analysis is unavailable; generated Go does not prove message/schema conformance.
Streaming classification, interceptors and clients are partial; runtime dispatch and messages are not observed.
How to interpret a result
Inspect the source location, revision and relationship kind. A recognized registration is static evidence; it does not establish runtime behavior or compatibility with every framework release. Unresolved or ambiguous targets should remain part of your review.
