GraphQL with Strawberry for Python APIs

Key facts, with sources

• Postman's 2025 State of the API report, based on more than 5,700 developers and API professionals, found 83.2% of respondents adopting some level of an API-first approach. (Postman State of the API 2025)
• The same Postman 2025 research found 65% of organizations now generate revenue directly from their API programs. (Postman State of the API 2025)
• One in four developers (24%) now design APIs specifically for consumption by AI agents, while 89% use generative AI tools in their daily work. (Business Wire)
• APIs make up 57% of the dynamic (non-cacheable) internet traffic processed by Cloudflare, and that share continues to grow. (Cloudflare)
• Salt Security's 2024 State of API Security report found 95% of respondents experienced API security problems in production, with security incidents more than doubling year over year from 17% to 37% of organizations. (Salt Security)

Why Strawberry over Graphene

Graphene predates modern Python typing, so its schemas are built from custom field classes that your type checker cannot see through. Strawberry inverts this: a GraphQL type is a decorated class with annotations, so mypy and your IDE validate resolvers the same way they validate any other function. When a resolver returns the wrong shape, I find out at type-check time, not when a client query fails.

Strawberry is also async-native, which matters because GraphQL resolvers fan out — a single query can trigger dozens of awaits, and blocking resolvers in an async FastAPI app will stall the event loop. The maintainers ship first-class FastAPI integration, so there is no adapter glue to maintain.

Mounting a schema on FastAPI

The integration is a router. You define query types, build a schema, and include the GraphQLRouter like any other FastAPI router. The context_getter hook is where dependency injection happens — I use it to hand resolvers a database session, the authenticated user, and per-request dataloaders.

One production note: the GraphiQL playground the router serves by default is great in development, but I disable it in production or gate it behind auth, since it advertises your whole schema to anyone who finds the endpoint.

import strawberry
from fastapi import FastAPI
from strawberry.fastapi import GraphQLRouter


@strawberry.type
class Project:
    id: strawberry.ID
    name: str
    status: str


@strawberry.type
class Query:
    @strawberry.field
    async def projects(self, info: strawberry.Info) -> list[Project]:
        repo = info.context["project_repo"]
        return await repo.list_active()


async def get_context() -> dict:
    return {"project_repo": ProjectRepo()}


schema = strawberry.Schema(query=Query)
graphql_app = GraphQLRouter(schema, context_getter=get_context)

app = FastAPI()
app.include_router(graphql_app, prefix="/graphql")

Killing N+1 queries with DataLoader

The first thing I check in any GraphQL code audit is whether nested resolvers hit the database per object. A query for fifty posts with authors will fire fifty-one queries unless author lookups are batched. Strawberry ships a DataLoader that collects all the loads triggered during one execution tick and hands your batch function a single list of keys.

The critical detail: create loaders per request inside context_getter, never at module level. A module-level loader caches across requests, which leaks data between users and serves stale rows after writes.

from strawberry.dataloader import DataLoader


async def load_authors(author_ids: list[int]) -> list[Author]:
    rows = await fetch_authors_by_ids(author_ids)  # single SQL query
    by_id = {row.id: row for row in rows}
    return [by_id[author_id] for author_id in author_ids]


@strawberry.type
class Post:
    id: int
    author_id: strawberry.Private[int]

    @strawberry.field
    async def author(self, info: strawberry.Info) -> Author:
        return await info.context["author_loader"].load(self.author_id)


async def get_context() -> dict:
    return {"author_loader": DataLoader(load_fn=load_authors)}

Auth and permissions inside the graph

I resolve authentication once, before GraphQL executes: the context_getter reads the bearer token, loads the user, and puts it in context. Resolvers then only make authorization decisions. Strawberry supports permission classes attached to individual fields, which is the right granularity for GraphQL — a query can legitimately touch both public and private fields, so route-level auth is too coarse.

Keep permission checks cheap and synchronous where possible. A permission class that performs its own database query per field multiplies load invisibly; if a check needs data, load it through the same dataloaders the resolvers use.

Production guardrails before launch

A public GraphQL endpoint is a query engine you are handing to strangers, so I never ship one without limits. Query depth limiting stops deeply nested queries from expanding into enormous joins; Strawberry supports this through schema extensions such as its query depth limiter. Pair it with a hard timeout on the request and a cap on response size.

For client-facing mobile apps, persisted queries — where the app registers its queries at build time and sends only an identifier — close the arbitrary-query hole entirely and shrink request payloads. Finally, log the operation name and resolver timings for every request; without that, GraphQL's single-endpoint design makes your API a blind spot in every dashboard you own.

When to hire senior help

Bring in senior backend help when you are defining the public contract of your API (auth model, versioning, rate limits), because those decisions are nearly impossible to change once partners integrate. It is also warranted when incidents like timeout cascades, N+1 query storms, or authorization bugs start appearing, since these are pattern problems a senior engineer has usually fixed many times before. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Python — Backend APIs projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Shipping list endpoints without pagination or rate limiting, then having one integration partner's bulk pull take down the database
• ✕Launching with no versioning strategy, so the first breaking schema change strands mobile apps that cannot be force-updated
• ✕Missing per-object authorization checks (broken object-level authorization), letting any authenticated user read other tenants' records by iterating IDs
• ✕Treating internal APIs as trusted and undocumented, then exposing them to partners or frontends later without adding auth, quotas, or contracts

Frequently asked questions

Sources

• Postman State of the API 2025
• Business Wire
• Cloudflare
• Salt Security