0Pricing
FastAPI Backend Development Bootcamp · レッスン

型、クエリ、ミューテーションの定義

Strawberryで型付きGraphQLスキーマを構築し、共有依存関係を持つFastAPIアプリにマウントします。

「型、クエリ、ミューテーションの定義」はCoddyKit上の無料FastAPI Backend Development Bootcampレッスンです。 これはレッスン1/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはFastAPI Backend Development Bootcamp学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 FastAPI Backend Development Bootcampコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Why Strawberry for GraphQL on FastAPI

Strawberry is a code-first GraphQL library for Python that uses dataclasses and type hints to define your schema. Instead of writing GraphQL SDL by hand, you write plain Python classes and Strawberry derives the schema from them.

  • Code-first: the Python types ARE the source of truth — the SDL is generated.
  • Type-safe: standard type hints (int, str, list[str], Optional) map directly to GraphQL types.
  • ASGI-native: ships a router that mounts cleanly on a FastAPI app, sharing its event loop and dependency system.

In this lesson we build a typed schema (types, a Query, and a Mutation) and mount it on FastAPI with shared dependencies.

Defining an Object Type

A GraphQL object type is just a class decorated with @strawberry.type. Each annotated attribute becomes a field. Type hints determine the GraphQL field type: int becomes Int, str becomes String, and a non-optional field becomes non-null (!).

  • Use strawberry.ID for identifier fields — it serializes as a string but signals identity semantics.
  • Optional[...] (or X | None) makes a field nullable.
import strawberry
from typing import Optional


@strawberry.type
class Book:
    id: strawberry.ID
    title: str
    author: str
    pages: int
    summary: Optional[str] = None

The Query Root Type

Every GraphQL schema needs a Query root — the entry point for reads. You declare it as a @strawberry.type whose fields are resolved by methods decorated with @strawberry.field.

  • The method's return annotation defines the field's GraphQL type.
  • Method parameters (other than self) become GraphQL arguments.
  • Returning a list[Book] produces a non-null list of non-null books: [Book!]!.
import strawberry


@strawberry.type
class Query:
    @strawberry.field
    def books(self) -> list[Book]:
        return [
            Book(id="1", title="Dune", author="Herbert", pages=412),
            Book(id="2", title="1984", author="Orwell", pages=328),
        ]

    @strawberry.field
    def book(self, id: strawberry.ID) -> Book | None:
        for b in self.books():
            if b.id == id:
                return b
        return None

Building the Schema

strawberry.Schema ties root types together. At minimum you pass query=Query; later you add mutation=Mutation. Building the schema validates your types and lets you print the generated SDL — a great sanity check.

Here is a fully standalone example: define a type, a query, build the schema, and execute a query synchronously with schema.execute_sync. No server or framework needed.

import strawberry


@strawberry.type
class Book:
    id: strawberry.ID
    title: str
    author: str


@strawberry.type
class Query:
    @strawberry.field
    def books(self) -> list[Book]:
        return [Book(id="1", title="Dune", author="Herbert")]


schema = strawberry.Schema(query=Query)

result = schema.execute_sync("{ books { id title author } }")
print(result.errors)
print(result.data)

Field Arguments and Defaults

GraphQL arguments come straight from resolver parameters. A parameter with a default value becomes an optional argument; without a default it is required.

  • Use typing.Optional + a default to express a nullable, optional argument.
  • Strawberry coerces incoming argument values to the annotated Python type automatically.

Below, limit defaults to 10 and genre is an optional filter.

import strawberry
from typing import Optional


@strawberry.type
class Book:
    id: strawberry.ID
    title: str
    genre: str


LIBRARY = [
    Book(id="1", title="Dune", genre="scifi"),
    Book(id="2", title="It", genre="horror"),
]


@strawberry.type
class Query:
    @strawberry.field
    def books(self, limit: int = 10, genre: Optional[str] = None) -> list[Book]:
        items = LIBRARY if genre is None else [b for b in LIBRARY if b.genre == genre]
        return items[:limit]


schema = strawberry.Schema(query=Query)
print(schema.execute_sync('{ books(genre: "scifi") { title } }').data)

Input Types for Mutations

Mutations that accept structured data should use an input type: a class decorated with @strawberry.input. Input types are the GraphQL equivalent of a request body — they keep mutation signatures clean and self-documenting.

  • Fields without defaults are required input fields.
  • Reuse the same input across create/update flows by making fields optional where appropriate.
import strawberry
from typing import Optional


@strawberry.input
class AddBookInput:
    title: str
    author: str
    pages: Optional[int] = None

The Mutation Root Type

The Mutation root mirrors Query but expresses writes. Each method is a @strawberry.mutation. Convention: take an input type, perform the side effect, and return the created or updated object so the client can read fresh fields in one round trip.

This example keeps an in-memory store and returns the new Book. It is fully standalone and runnable.

import strawberry

_DB: list["Book"] = []


@strawberry.type
class Book:
    id: strawberry.ID
    title: str
    author: str


@strawberry.input
class AddBookInput:
    title: str
    author: str


@strawberry.type
class Query:
    @strawberry.field
    def books(self) -> list[Book]:
        return _DB


@strawberry.type
class Mutation:
    @strawberry.mutation
    def add_book(self, data: AddBookInput) -> Book:
        book = Book(id=str(len(_DB) + 1), title=data.title, author=data.author)
        _DB.append(book)
        return book


schema = strawberry.Schema(query=Query, mutation=Mutation)
q = 'mutation { addBook(data: {title: "Dune", author: "Herbert"}) { id title } }'
print(schema.execute_sync(q).data)

Async Resolvers

Because Strawberry runs on ASGI, resolvers can be async. This matters on FastAPI: your resolvers will await database calls, HTTP clients, or cache lookups without blocking the event loop.

  • Just declare async def — Strawberry awaits it for you.
  • Mix sync and async resolvers freely in the same schema.
  • Use async resolvers for any I/O so a single GraphQL request with many fields stays non-blocking.
import strawberry
import asyncio


@strawberry.type
class Stats:
    total_books: int


async def fetch_count() -> int:
    await asyncio.sleep(0)  # stand-in for an async DB call
    return 42


@strawberry.type
class Query:
    @strawberry.field
    async def stats(self) -> Stats:
        return Stats(total_books=await fetch_count())


schema = strawberry.Schema(query=Query)
print(asyncio.run(schema.execute("{ stats { totalBooks } }")).data)

Mounting on FastAPI with GraphQLRouter

Strawberry ships strawberry.fastapi.GraphQLRouter, an APIRouter you mount with app.include_router. It serves the GraphQL endpoint and an in-browser IDE (GraphiQL) at the same path.

  • Pass your built schema to the router.
  • Mount it under a path like /graphql.
  • The router uses FastAPI's event loop, so async resolvers and FastAPI startup/shutdown events work together.

This is framework code, so it is not runnable on a bare judge.

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


@strawberry.type
class Query:
    @strawberry.field
    def hello(self) -> str:
        return "world"


schema = strawberry.Schema(query=Query)
graphql_app = GraphQLRouter(schema)

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

Sharing Dependencies via Context

The big payoff of mounting on FastAPI is shared dependencies. Pass a context_getter to GraphQLRouter — it is a FastAPI dependency callable, so it can itself Depends on a DB session, the current user, or a settings object.

Whatever the context getter returns is exposed to resolvers via strawberry.Info at info.context. This is how authentication and database sessions flow from FastAPI into your GraphQL resolvers.

from fastapi import Depends
from strawberry.fastapi import GraphQLRouter


async def get_db():
    # yield a real async session in production
    yield {"connection": "db-session"}


async def get_context(db=Depends(get_db)):
    return {"db": db, "role": "reader"}


graphql_app = GraphQLRouter(schema, context_getter=get_context)

Reading Context Inside Resolvers

To use the shared context, add an info: strawberry.Info parameter to a resolver. Strawberry injects it automatically and it never appears as a GraphQL argument. Access your dependencies through info.context.

  • info.context["db"] — the session provided by context_getter.
  • Use it to authorize: read the current user and raise on missing permissions.
  • The same context object is shared across every resolver in a single request.
import strawberry


@strawberry.type
class Query:
    @strawberry.field
    def current_role(self, info: strawberry.Info) -> str:
        return info.context["role"]

    @strawberry.field
    def secret(self, info: strawberry.Info) -> str:
        if info.context["role"] != "admin":
            raise Exception("forbidden")
        return "top-secret"

Quick Check: Sharing the DB session

You mounted a Strawberry schema on FastAPI and need each GraphQL resolver to use the same per-request database session that your REST endpoints get from a FastAPI dependency. What is the idiomatic Strawberry + FastAPI way to wire this up?

Recap

You built a typed GraphQL schema with Strawberry and mounted it on FastAPI:

  • Types: @strawberry.type classes with type-hinted fields; strawberry.ID for identifiers and Optional for nullable fields.
  • Query: the read root, with @strawberry.field resolvers whose parameters become GraphQL arguments.
  • Mutations: @strawberry.mutation methods that take an @strawberry.input type and return the affected object.
  • Schema: strawberry.Schema(query=Query, mutation=Mutation), verifiable with execute_sync.
  • FastAPI integration: mount with GraphQLRouter, and share DB sessions and auth through context_getter + info.context, reusing FastAPI's dependency injection.

This code-first, type-safe approach keeps your GraphQL API and your FastAPI app speaking the same language — Python type hints.

よくある質問

「型、クエリ、ミューテーションの定義」レッスンは無料ですか？

はい。「型、クエリ、ミューテーションの定義」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、FastAPI Backend Development Bootcampコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 FastAPI Backend Development Bootcampコースには全4レッスンが含まれています。

「型、クエリ、ミューテーションの定義」で何を学びますか？

Strawberryで型付きGraphQLスキーマを構築し、共有依存関係を持つFastAPIアプリにマウントします。 ブラウザで直接実行するハンズオンコードでFastAPI Backend Development Bootcampを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

FastAPI Backend Development Bootcampを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのFastAPI Backend Development Bootcampは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン1/4です。

「型、クエリ、ミューテーションの定義」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このFastAPI Backend Development Bootcampレッスンでコードを書いて実行できますか？

はい。すべてのFastAPI Backend Development Bootcampレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. 型、クエリ、ミューテーションの定義
  2. DataLoaderによるN+1クエリの解消
  3. リアルタイムGraphQLサブスクリプション
  4. クエリコスト分析と深さ制限
← FastAPI Backend Development Bootcampに戻る