#Context
You're viewing documentation for a previous version of this software. Switch to the latest stable version
GraphQLSwift/GraphQL allow a custom data structure to be passed into all of your field resolver functions. This allows you to apply some dependency injection to your API and put any code that talks to a database or get the values from the request.
#Context, Request and Response
Pioneer provide a similar solution to apollo-server-express
for building context using the raw http requests and http responses. It provide both in the context builder that needed to be provided when constructing Pioneer.
Request specific
This request and response will be request-specific / different for each GraphQL HTTP request.
#Request (HTTP)
The request given is directly from Vapor, so you can use any method you would use in a regular Vapor application to get any values from it.
#Response
Pioneer already provided the response object in the context builder that is going to be the one used to respond to the request. You don't need return one, and instead just mutate its properties.
Returning custom response
There is currently no way for a resolver function to return a custom response. GraphQLSwift/GraphQL only take functions that return the type describe in the schema, and Pioneer also have to handle encoding the returned value into a response that follow the proper GraphQL format.
#Websocket Context
Since 0.7.0
, Pioneer allow a seperate context builder for the websocket operations where it provide a different set of arguments.
This context builder is similar to what you can provide to the context
property in graphql-ws
where you are given the Request
, Payload
, and GraphQLRequest
.
Shared Context Builder
By default if you don't provide a seperate context builder for websocket, Pioneer will try to use the regular contextBuilder
, by passing a custom request and a dummy response (that serve no value).
The custom request will similar to the request used to upgrade to websocket but will have:
- The headers taken from
"header"/"headers"
value from thePayload
or all the entirety ofPayload
- The query parameters taken from
"query"/"queries"/"queryParams"/"queryParameters"
value from thePayload
- The body from the
GraphQLRequest
Only when using shared builder
These addition only apply when using shared context builder. If not, the request will be the exact one from the upgrade request with no custom headers
#Request (WS)
The request given is directly from Vapor when upgrading to websocket, so you can use any method you would use in a regular Vapor application to get any values from it.
Switching Protocol Request
This request object will be the same for each websocket connection and will not change unless the new connection is made.
It will also not have any custom headers and the operation specific graphql query which is different from request given in HTTP.
#Payload
The connection params is given during websocket initialization from payload
as part of ConnectionInit
message inside an established WebSocket connection.
#GraphQLRequest
This is operation specific graphql request / query given an operation is being executed.
There might be times where you want to authorize any incoming WebSocket connection before any operation done, and thus before the context builder is executed.
Since v0.10.0
, Pioneer now provide a way to run custom code during the GraphQL over WebSocket initialisation phase that can deny a WebSocket connection by throwing an error.