Graphtia documentation · reference
Python framework analysis: FastAPI, Django, Flask, SQLAlchemy and Celery
See how Explorer recognizes FastAPI, Django, Flask, SQLAlchemy, Celery, 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: FastAPI · Django · Flask · SQLAlchemy · Celery
FastAPI
Trace declared routes and exact handler/dependency bindings, including supported nested router prefixes and Depends chains.
Which handler and dependency lie behind this mounted route?
Evidence to inspect- Static include_router /api to GET /api/ordersunique literal mount
- GET /api/orders to list_orders handlerhandler binding
- list_orders handler to current_user dependencyDepends binding
Trace a uniquely mounted literal router prefix to its endpoint and inspect exact handler and Depends bindings.
Overrides, ambiguous mounts, callable factories and runtime middleware remain unresolved. Source identities support the route and dependency links; the application is not imported.
How it is recognized
Exact FastAPI/APIRouter import and constructor/decorator evidence in indexed Python source.
Relationships you can inspect
Literal HTTP decorators and uniquely mounted include_router prefix chains.
Exact handler, Depends and nested dependency function bindings.
Literal endpoint metadata such as names/tags/status/response-model references and bounded Pydantic structural associations.
Required source context
Accepted Python facts and proven imports; an APIRouter needs one static path to a FastAPI application before it is treated as an application HTTP provider.
Coverage limits
Callable dependencies, Pydantic semantics and factories are partial.
Dynamic/ambiguous mounts, dependency overrides, loops/monkey patches and runtime middleware order remain unresolved; no application is imported or started.
Django
Explore supported URL-to-view links, model declarations, middleware literals and selected signal/command facts.
Which view does this included URL declaration reach?
Evidence to inspect- Root URL patterns to Literal orders/ includedeclared include
- Literal orders/ include to list/ child pathstatic path composition
- list/ child path to order_list viewexact view binding
Follow bounded literal URL includes into an exact function or class-based view while keeping unsupported router behavior explicit.
Dynamic settings, custom converters, app-registry execution and general DRF router behavior are not inferred. Literal include composition explains the source path to the view.
How it is recognized
Exact Django import identity and recognizable URL/model/settings declarations.
Relationships you can inspect
path/re_path and bounded literal include composition; exact function or class-based view bindings.
Models/fields and uniquely resolvable relationship strings.
Ordered literal middleware, selected settings/signals and management-command entry points.
Required source context
Accepted Python facts; literal path and exact local/imported view identity. Relative view imports require a known parent package.
Coverage limits
Includes, relationships, signals, DRF and dynamic settings are partial.
Custom converters, app registry, migrations, generic view dispatch, DRF routers/serializers and ORM execution are not inferred.
Flask
Inspect static routes, handler links, Blueprint prefixes/registration and request-hook declarations.
Is this Blueprint route registered under one known prefix?
Evidence to inspect- register_blueprint with /api to Orders Blueprintsingle static registration
- Orders Blueprint to GET /api/ordersdeclared effective prefix
- GET /api/orders to list_orders handlerhandler binding
Inspect a uniquely registered Blueprint, its literal prefix and the route's exact handler.
Multiple or dynamic registrations, factory execution and hook order can remain unresolved. A uniquely proven registration supports the application provider; an unregistered Blueprint remains a declaration.
How it is recognized
Exact Flask/Blueprint constructor/import identity and supported decorators.
Relationships you can inspect
Literal methods/path and handler declarations.
Blueprint HTTP providers only with a single proven static registration/effective prefix.
Request hooks and conservative factory metadata.
Required source context
Accepted Python facts; exact local module imports for cross-file Blueprint registration.
Coverage limits
Unregistered, multiply registered or dynamically prefixed Blueprints can remain declarations without application providers.
Dynamic/nested registration, extension routes, nested factory execution, hook order and WSGI behavior remain unresolved.
SQLAlchemy
Inspect mapped classes, explicit columns/tables and uniquely identified model relationships as source structure.
Which mapped relationship target is declared for this model?
Evidence to inspect- Order mapped class to customer relationshipdeclares relationship
- customer relationship to Customer mapped classunique model target
- Order mapped class to Declared table name: ordersmapping declaration
Inspect explicit mapped classes, table names and uniquely identifiable relationship targets before changing a model.
Reflection, automap, runtime mapper configuration and query results are not inferred. Model relationships are source structure. Code-to-SQL-table matching is a separate, narrowly supported analysis.
How it is recognized
Recognized exact SQLAlchemy imports and supported modern/classic declarative forms.
Relationships you can inspect
DeclarativeBase/declarative_base, mapped classes, mapped_column/Column and tables.
Uniquely proven relationship targets and partial source-visible Session usage.
Required source context
Accepted Python facts, import identity and explicit mappings; string relationships must identify one target in scope.
Coverage limits
Relationships and sessions are partial; query semantics are unavailable.
Reflection/automap, runtime mapper configuration, metaprogramming, migrations, engine behavior and query results are not inferred.
Celery
Connect recognized task declarations and producers through static task identities, with source-declared queue metadata.
Which declared task matches this static producer name?
Evidence to inspect- send_task producer to orders.confirm task identityconsumer identity
- orders.confirm task identity to confirm_order task functionscoped task declaration
- confirm_order task function to Declared checkout queuequeue metadata
Inspect a recognized producer and a uniquely identified task in the same application scope, with source-declared queue metadata.
Dynamic names, autodiscovery, routing decisions, retries and task execution remain unobserved. This is static task-boundary evidence, not a normal function call or proof of broker delivery.
How it is recognized
Exact Celery constructors and app.task/shared_task decorator evidence.
Relationships you can inspect
Task names and supported declared queues.
delay/apply_async/send_task producer candidates and task providers for the async-task boundary.
Required source context
Accepted Python facts and one unique task name in the same application scope.
Coverage limits
Queue/routing, canvas and retry interpretation are partial; dynamic names/autodiscovery remain unresolved.
No broker topology, delivery or execution outcome is observed; producer-to-task links are boundary relations, not fabricated ordinary calls.
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.