FastAPI
Strawberry provides support for FastAPI with a
custom
APIRouter
called GraphQLRouter
.
Before using Strawberry’s FastAPI support make sure you install all the required dependencies by running:
See the example below for integrating FastAPI with Strawberry:
Options
The GraphQLRouter
accepts the following options:
-
schema
: mandatory, the schema created bystrawberry.Schema
. -
graphql_ide
: optional, defaults to"graphiql"
, allows to choose the GraphQL IDE interface (one ofgraphiql
,apollo-sandbox
orpathfinder
) or to disable it by passingNone
. -
allow_queries_via_get
: optional, defaults toTrue
, whether to enable queries viaGET
requests -
context_getter
: optional FastAPI dependency for providing custom context value. -
root_value_getter
: optional FastAPI dependency for providing custom root value. -
multipart_uploads_enabled
: optional, defaults toFalse
, controls whether to enable multipart uploads. Please make sure to consider the security implications mentioned in the GraphQL Multipart Request Specification when enabling this feature.
context_getter
The context_getter
option allows you to provide a custom context object that
can be used in your resolver. context_getter
is a
FastAPI dependency and
can inject other dependencies if you so wish.
There are two options at your disposal here:
- Define your custom context as a dictionary,
- Define your custom context as a class.
If no context is supplied, then the default context returned is a dictionary containing the request, the response, and any background tasks.
However, you can define a class-based custom context inline with
FastAPI practice .
If you choose to do this, you must ensure that your custom context class
inherits from BaseContext
or an InvalidCustomContext
exception is raised.
For dictionary-based custom contexts, an example might look like the following.
Here we are returning a custom context dictionary that contains one extra item
called “customvalue”, which is injected from custom_context_dependency
. This
value exists alongside request
, response
, and background_tasks
in the
info.context
_dictionary and so it requires ['request']
indexing.
Then we use the context in a resolver. The resolver will return “Hello John” in this case.
For class-based custom contexts, an example might look like the following.
In this case, we are returning a custom context class that inherits from
BaseContext with fields name
and greeting
, which is also injected by
custom_context_dependency
. These custom values exist alongside request
,
response
, and background_tasks
in the info.context
class and so it
requires .request
indexing.
Then we use the context in a resolver. The resolver will return “Hello John, you rock!” in this case.
Setting background tasks
Similarly, background tasks can be added via the context:
If using a custom context class, then background tasks should be stored within
the class object as .background_tasks
.
root_value_getter
The root_value_getter
option allows you to provide a custom root value for
your schema. This is most likely a rare usecase but might be useful in certain
situations.
Here’s an example:
Here we are returning a Query where the name is “Patrick”, so when we request the field name we’ll return “Patrick”.
Extending the router
The base GraphQLRouter
class can be extended by overriding any of the
following methods:
-
async def process_result(self, request: Request, result: ExecutionResult) -> GraphQLHTTPResponse
-
def decode_json(self, data: Union[str, bytes]) -> object
-
def encode_json(self, data: object) -> str
-
async def render_graphql_ide(self, request: Request) -> HTMLResponse
-
async def on_ws_connect(self, context: Context) -> Union[UnsetType, None, Dict[str, object]]
process_result
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.