#Integrations
#Open-Source Integrations
Exisiting first-party of community maintained integrations for Pioneer:
#Building integrations
This section is for authors of web frameworks integrations. Before building a new integration, it's recommended seeing if there's an integration for your framework of choice that suits your needs
#Implementing GraphQL over HTTP
First, the HTTP layer. Pioneer provide a method .executeHTTPGraphQLRequest which is the base layer of an GraphQL would look like HTTP handler.
All that is missing to use that method is translating the web-framework native request object into HTTPGraphQLRequest.
#Mapping into HTTPGraphQLRequest
HTTPGraphQLRequest only require 3 properties: the GraphQLRequest object, the HTTP headers, and the HTTP method.
The important part is parsing into GraphQLRequest. A recommended approach in parsing is:
- Parse GraphQLRequest from the body of a request. (Usually for POST)
- If it's not in the body, get the values from the query/search parameters. (Usually for GET)
- The query string should be under
query
- The operation name should be under
operationName
- The variables should be under
variables
as JSON string- This is probably percent encoded, and also need to be parse into
[String: Map]?
if available
- This is probably percent encoded, and also need to be parse into
- As long the query string is accessible, the request is not malformed and we can construct a GraphQLRequest using that.
- The query string should be under
- If GraphQLRequest can't be retreive by both approach 1 and 2, the request is malformed and the response could also have status code of 400 Bad Request.
#Getting the context
It's important that the context should be computed / derived for each request. By convention, it's best to allow user of the integration to compute the context from the request and the response object of the web-framework.
If the compute function is allowed to be asynchronous, make sure to make it Sendable
conformance by adding the @Sendable
function wrapper.
#Executing and using HTTPGraphQLResponse
Once, there is a way to retreive HTTPGraphQLRequest and the context. All is needed is to execute the request and mapped the HTTPGraphQLRequest into the web-framework response object.
#Implementing GraphQL IDE
This is part is relatively simple, send back the web-framework response that contains the HTML for the given IDE or a redirect if the IDE was set to be a redirect.
The HTML for each type of IDE are available as computed properties of Pioneer. The URL for the Cloud IDEs are accessible property.
All that is needed is to serve this HTML and redirect if the IDE option is a redirect using the URL given.
#Implemeting GraphQL over WebSocket
Implementing the WebSocket layer can be tricky to do. Pioneer already provide all the callbacks need to setup GraphQL over WebSocket, the only thing missing is to connect that to the WebSocket portion of the web-framework.
#Upgrading HTTP Request into WebSocket
It is important that the desired web-framework can be used to perform upgrade to WebSocket from a regular HTTP requests.
The only thing needed to be done before the upgrade is done, is to check whether the Sec-WebSocket-Protocol
header value is matching the WebSocket protocol name
#Context and Guard
Before proceeding, similarly to HTTP, context is a crutial part of the GraphQL operation. By convention for WebSocket, it's best to allow user of the integration to compute the context from the request, the initial payload, and the GraphQL operation itself.
The only other addition is WebSocket guard. It is also desirable for the user to be able to perform action just after the initialisation process using the request and the initial payload.
#Making WebSocket WebSocketable
In order for Pioneer to use the web-framework specific implementation of WebSocket. The web-framework WebSocket object must conforms the WebSocketable protocol.
#Setting up GraphQL over WebSocket
After the upgrade is done, there's only a few things to do:
- Create a new
UUID
to uniquely identify the connection. - Setup
Task
s for keeping the connection alive and timeout connection if initialisation didn't happen.- This can be performed using the .keepAlive and the .timeout method.
- .timeout might want to be called after .keepAlive, because it optionally require the keep alive task as an argument.
- Creating a task or a stream to consume the incoming WebSocket messages
- .receiveMessage method is used here.
- For consuming the incoming message, if in the web-framework it is done in a callback, it is best to pipe that value into an AsyncStream first and iterate through the AsyncStream before calling the .receiveMessage method.
- Setting up callback for when the connection has been closed.
- .closeClient method is used here.
- It is also recommended if possible to stop the consuming incoming message here as well.