Strawberry comes with an integration for Litestar by
providing a make_graphql_controller function that can be used to create a
GraphQL controller.
See the example below for integrating Litestar with Strawberry:
Options
The make_graphql_controller function accepts the following options:
schema : mandatory, the schema created by strawberry.Schema .
path : optional, defaults to “, the path where the GraphQL endpoint will be
mounted.
graphql_ide : optional, defaults to "graphiql" , allows to choose the
GraphQL IDE interface (one of graphiql , apollo-sandbox or pathfinder ) or
to disable it by passing None .
allow_queries_via_get : optional, defaults to True , whether to enable
queries via GET requests
context_getter : optional Litestar dependency for providing custom context
value.
root_value_getter : optional Litestar dependency for providing custom root
value.
debug : optional, defaults to False , whether to enable debug mode.
keep_alive : optional, defaults to False , whether to enable keep alive mode
for websockets.
keep_alive_interval : optional, defaults to 1 , the interval in seconds for
keep alive messages.
subscription_protocols optional, defaults to
(GRAPHQL_TRANSPORT_WS_PROTOCOL, GRAPHQL_WS_PROTOCOL) , the allowed
subscription protocols
connection_init_wait_timeout optional, default to timedelta(minutes=1) ,
the maximum time to wait for the connection initialization message when using
graphql-transport-wsprotocol
The context_getter option allows you to provide a Litestar dependency that
return a custom context object that can be used in your resolver.
The context_getter is a standard Litestar dependency and can receive any
existing dependency:
You can also use a class-based custom context. To do this, you must inherit from
BaseContextmsgspec Struct or
an InvalidCustomContext exception will be raised.
Context typing
In our previous example using class based context, the actual runtime context a
CustomContext type. Because it inherits from BaseContext , the request ,
socket and response attributes are typed as optional.
When inside a query/mutation resolver, request and response are always set
and socket is only set in subscriptions.
To distinguish theses cases typing wise, the integration provides two classes
that will help you to enforce strong typing:
These classes does not actually exists at runtime, they are intended to be used
to define a custom Info type with proper context typing. Taking over our
previous example with class based custom context, here it how we can define two
Info types for both queries/mutations and subscriptions:
root_value_getter
The root_value_getter option allows you to provide a custom root value that
can be used in your resolver
Extending the controller
The base GraphQLController class returned by make_graphql_controller can be
extended by overriding any of the following methods:
The process_result option allows you to customize and/or process results
before they are sent to the clients. This can be useful for logging errors or
hiding them (for example to hide internal exceptions).
It needs to return a GraphQLHTTPResponse object and accepts the request and
execution results.
In this case we are doing the default processing of the result, but it can be
tweaked based on your needs.
decode_json
decode_json allows to customize the decoding of HTTP and WebSocket JSON
requests. By default we use json.loads but you can override this method to use
a different decoder.
Make sure your code raises json.JSONDecodeError or a subclass of it if the
JSON cannot be decoded. The library shown in the example above, orjson , does
this by default.
encode_json
encode_json allows to customize the encoding of HTTP and WebSocket JSON
responses. By default we use json.dumps but you can override this method to
use a different encoder.
render_graphql_ide
In case you need more control over the rendering of the GraphQL IDE than the
graphql_ide option provides, you can override the render_graphql_ide method.
on_ws_connect
By overriding on_ws_connect you can customize the behavior when a graphql-ws
or graphql-transport-ws connection is established. This is particularly useful
for authentication and authorization. By default, all connections are accepted.
To manually accept a connection, return strawberry.UNSET or a connection
acknowledgment payload. The acknowledgment payload will be sent to the client.
Note that the legacy protocol does not support None /null acknowledgment
payloads, while the new protocol does. Our implementation will treat
None /null payloads the same as strawberry.UNSET in the context of the
legacy protocol.
To reject a connection, raise a ConnectionRejectionError . You can optionally
provide a custom error payload that will be sent to the client when the legacy
GraphQL over WebSocket protocol is used.