You can import it using remote/local
To get started, install the handler library from NPM:
Now, you can use it directly in your Mesh config file:
By default OpenAPI-to-GraphQL will place all GET operations into Query fields and all other operations into Mutation fields; with this option you can manually override this process. In order to switch between Query and Mutation operations, and vice versa, you need to define a rule per override, consisting of: OAS title, path of the operation, method of the operation and finally the destination type (e.g. Query or Mutation). See example below:
Mesh can take dynamic values from the GraphQL Context or the environmental variables. If you use
mesh serve, GraphQL Context will be the incoming HTTP request.
The expression inside dynamic values should be as in JS.
From Context (HTTP Header for
mesh serve, you can pass the value using
x-my-graphql-api-token HTTP header.
MY_API_TOKEN is the name of the environmental variable you have the value.
When building a web application, for security reasons, cookies are often used for authentication. Mobile applications on the other end, tend to use a HTTP header.
This section shows how to configure GraphQL Mesh to accept either, and also how to use GraphQL Mesh to set / unset cookies on the login & logout mutations.
We want to accept either a
accessToken cookie or a
Authorization header, and transmit it to the Rest API as a
Authorization header. GraphQL Mesh does not allow dynamic selection in the
meshrc.yaml file, but that's fine! We can use a bit of trickery.
Here in the
meshrc.yaml configuration we store the cookie in
Authorization-Cookie, and the header in
Authorization-Header. Now to introduce the logic needed to generate the proper
Authorization header for the Rest API, we need to implement a
customFetch. It will replace the
fetch used by GraphQL Mesh to call the Rest API.
node-fetch needs to be added to your project:
npm add node-fetch.
Of course, being able to use GraphQL Mesh as a Gateway for both the mobile application and web application is nice, but there's one thing missing: the setting of the cookie for the web application.
For that, we need to access the HTTP response that is sent back to the client. Luckily, we can do so in
additionalResolvers. So we need to create two new resolvers, one for login and one for logout, and manage the cookie in their code.
The first step is to edit the
meshrc.yaml file, add this at the end:
Then manage the cookie in the new resolvers:
There's a caveat: the Rest API's login operation cannot have the same name as the additional login mutation. In this example we assumed that the login operation of the Rest API was named
accountLogin, thus avoiding the name conflict.
We have a lot of examples for OpenAPI Handler;
Any, required) - A pointer to your API source - could be a local file, remote file or url endpoint
String (json | yaml)) - Format of the source file
JSON) - JSON object representing the Headers to add to the runtime of the API calls
JSON) - If you are using a remote URL endpoint to fetch your schema, you can set headers for the HTTP request to fetch your schema.
String) - Specifies the URL on which all paths will be based on. Overrides the server object in the OAS.
JSON) - JSON object representing the query search parameters to add to the API calls
Any) - W3 Compatible Fetch Implementation
Boolean) - Include HTTP Response details to the result object
Boolean) - Auto-generate a 'limit' argument for all fields that return lists of objects, including ones produced by links
Boolean) - Set argument name for mutation payload to 'requestBody'. If false, name defaults to camelCased pathname
Array of Object) - Allows to explicitly override the default operation (Query or Mutation) for any OAS operation:
String) - OAS Title
String) - Operation Path
String (Query | Mutation)) - Target Root Type for this operation
String) - Which method is used for this operation