Pydantic support
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.
Input types
Input types are similar to types; we can create one by using the
strawberry.experimental.pydantic.input
decorator:
Interface types
Interface types are similar to normal types; we can create one by using the
strawberry.experimental.pydantic.interface
decorator:
Error Types
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
Extending types
You can use the usual Strawberry syntax to add additional new fields to the GraphQL type that arenβt defined in the pydantic model
Converting types
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:
Constrained types
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.
Classes with __get_validators__
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.
Custom Conversion Logic
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.