Quick Start
In this Quick-Start, we will:
- Set up a basic pair of models with a relation between them.
- Add them to a graphql schema and serve the graph API.
- Query the graph API for model contents.
For a more advanced example of a similar setup including a set of mutations and more queries, please check the example app .
Installation
(Not using poetry yet? pip install strawberry-graphql-django
works fine too.)
Define your application models
We’ll build an example database of fruit and their colours.
Tip
You’ll notice that for Fruit.category
, we use TextChoicesField
instead of TextField(choices=...)
.
This allows strawberry-django to automatically use an enum in the graphQL schema, instead of
a string which would be the default behaviour for TextField.
See the choices-field integration for more information.
You’ll need to make migrations then migrate:
Now use the django shell, the admin, the loaddata command or whatever tool you like to load some fruits and colors. I’ve loaded a red strawberry (predictable, right?!) ready for later.
Define types
Before creating queries, you have to define a type
for each model. A type
is a fundamental unit of the schema
which describes the shape of the data that can be queried from the GraphQL server. Types can represent scalar values (like String, Int, Boolean, Float, and ID), enums, or complex objects that consist of many fields.
Tip
A key feature of strawberry-graphql-django
is that it provides helpers to create types from django models,
by automatically inferring types (and even documentation!!) from the model fields.
See the fields guide for more information.
Build the queries and schema
Next we want to assemble the schema from its building block types.
Warning
You’ll notice a familiar statement, fruits: list[Fruit]
. We already used this statement in the previous step in types.py
.
Seeing it twice can be a point of confusion when you’re first getting to grips with graph and strawberry.
The purpose here is similar but subtly different. Previously, the syntax defined that it was possible to make a query that traverses within the graph, from a Color to a list of Fruits. Here, the usage defines a root query (a bit like an entrypoint into the graph).
Tip
We add the DjangoOptimizerExtension
here. Don’t worry about why for now, but you’re almost certain to want it.
See the optimizer guide for more information.
Serving the API
Now we’re showing off. This isn’t enabled by default, since existing django applications will likely have model docstrings and help text that aren’t user-oriented. But if you’re starting clean (or overhauling existing dosctrings and helptext), setting up the following is super useful for your API users.
If you don’t set these true, you can always provide user-oriented descriptions. See the
This generates following schema:
Using the API
Start your server with:
Then visit localhost:8000/graphql in your browser. You should see the graphql explorer being served by django. Using the interactive query tool, you can query for the fruits you added earlier:
Next steps
- Defining more Django Types
- Define Fields inside those Types
- Serve your API using ASGI or WSGI
- Define filters for your fields
- Define orderings for your fields
- Define pagination for your fields
- Define queries for your schema
- Define mutations for your schema
- Define subscriptions for your schema
- Enable the Query Optimizer extension for performance improvement
- Use the relay integration for advanced pagination and model refetching
- Protect your fields using the Permission Extension
- Write unit tests for your schema