Graphtia documentation · reference
Framework support: routes, components, models and services
Explore framework-specific routes, handlers, components, model mappings and task relationships, with detailed source requirements and coverage limits.
Choose the technology you use, then follow a concrete source relationship: a route and handler, a component reference, a service registration or a model mapping. Each example shows supported static evidence and the limits that remain.
Find your stack
Components, web routes, hooks and controllers.
HTTP routes, middleware and generated RPC bindings.
Application frameworks, REST specifications and persistence mappings.
Web endpoints, service registrations, models and RPC bindings.
Web routes, models, dependencies and asynchronous task declarations.
Source evidence linking supported SQL sites to declared tables.
Logo credits
Gin logo by Javier Provecho, CC BY 4.0; original gopher eyes by Renee French, CC BY 3.0. Monochrome geometry from Simple Icons, displayed in its catalog color.
Fiber logo by Vic Shóstak, CC BY-SA 4.0. Original artwork, displayed at a smaller size without alteration.
What framework support adds
Recognized routes and their handler candidates, with explicit source context.
Component, service, dependency-injection, model or task declarations where the adapter supports them.
A clear distinction between a declared relationship, a supported binding and an unresolved target.
Supported source and project configuration can identify routes, components, services and model mappings. Inspect each result with its source and coverage conditions. Recognizing a framework does not certify every plugin or version.
Prepare a useful index
Include the source and project metadata used by your stack, such as package.json, go.mod, Composer or build/project declarations.
For generated APIs, include the generated source required by the relevant adapter.
Check any required packaged language analyzer and the actual indexing diagnostics.
Use the stack-specific page to check exact imports, literal declarations and source-identity requirements.
Frameworks, languages and boundaries are different inventories
The current registry has 23 framework-category adapters, including two DB-code evidence producers. React and Next.js share one adapter. Language support, generic communication boundaries and SQL dialects are separate inventories; adding their counts would not describe a number of independently supported frameworks.
Playwright, Vitest, Jest and Node test-runner recognition belongs to TypeScript/JavaScript language analysis. These four test-runner families are not additional framework-category adapters.
See recognized test patterns and their limits
Version and runtime scope
The guide describes source patterns recognized by Explorer. Recognition prerequisites, such as a declared language version or a package import, are not a certification of every framework version. Runtime containers, plugins, generated behavior and dynamic configuration can require separate validation.
A supported language does not imply every framework
Code in a supported language can still be analyzed without a dedicated framework enrichment layer. Angular, Vue/Nuxt, Svelte, Express/Nest/Fastify, Rails/Sinatra, Symfony, Axum/Actix and the Prisma, Drizzle, Sequelize, TypeORM, Mongoose, Knex, SQLx and Diesel libraries are not dedicated official adapters in the current inventory. A dependency name or an HTTP request to a service does not establish support for that service framework.