Strawberry comes with support for
Pydantic . This allows for the creation
of Strawberry types from pydantic models without having to write code twice.
Here’s a basic example of how this works, let’s say we have a pydantic Model for
a user, like this:
We can create a Strawberry type by using the
strawberry.experimental.pydantic.type decorator:
The strawberry.experimental.pydantic.type decorator accepts a Pydantic model
and wraps a class that contains dataclass style fields with strawberry.auto as
the type annotation. The fields marked with strawberry.auto will inherit their
types from the Pydantic model.
If you want to include all of the fields from your Pydantic model, you can
instead pass all_fields=True to the decorator.
-> Note Care should be taken to avoid accidentally exposing fields that ->
weren’t meant to be exposed on an API using this feature.
In addition to object types and input types, Strawberry allows you to create
"error types". You can use these error types to have a typed representation of
Pydantic errors in GraphQL. Let's see an example:
where each field will hold a list of error messages
The generated types won’t run any pydantic validation. This is to prevent
confusion when extending types and also to be able to run validation exactly
where it is needed.
To convert a Pydantic instance to a Strawberry instance you can use
from_pydantic on the Strawberry type:
If your Strawberry type includes additional fields that aren't defined in the
pydantic model, you will need to use the extra parameter of from_pydantic to
specify the values to assign to them.
The data dictionary structure follows the structure of your data -- if you have
a list of User , you should send an extra that is the list of User with the
missing data (in this case, age ).
You don’t need to send all fields; data from the model is used first and then
the extra parameter is used to fill in any additional missing data.
To convert a Strawberry instance to a pydantic instance and trigger validation,
you can use to_pydantic on the Strawberry instance:
Strawberry supports
pydantic constrained types .
Note that constraint is not enforced in the graphql type. Thus, we recommend
always working on the pydantic type such that the validation is enforced.
Pydantic BaseModels may define a custom type with
__get_validators__
logic. You will need to add a scalar type and add the mapping to the
scalar_overrides argument in the Schema class.
Sometimes you might not want to translate your Pydantic model into Strawberry
using the logic provided in the library. Sometimes types in Pydantic are
unrepresentable in GraphQL (such as unions of scalar values) or structural
changes are needed before the data is exposed in the schema. In these cases,
there are two methods you can use to control the conversion logic more directly.
First, you can use a different type annotation in your Strawberry model for a
field type instead of using strawberry.auto to choose an equivalent type. This
allows you to do things like converting values to custom scalar types or
converting between basic types. Strawberry will call the constructor of the new
type annotation with the field value as input, so this only works when
conversion is possible through a constructor.
The other, more comprehensive, method for modifying the conversion logic is to
provide custom implementations of from_pydantic and to_pydantic . This allows
you full control over the conversion process and bypasses Strawberry’s built in
conversion rules completely, while still registering the new type as a Pydantic
conversion type so it can be referenced in other models.
This is useful when you need to represent structures that are very different
from GraphQL standards, without changing the underlying Pydantic model. An
example would be a use case that uses a dict field to store some
semi-structured content, which is difficult to represent in GraphQL’s strict
type system.