graphql-http

GraphQL on HTTP middleware with built-in validations and GraphQL playground

What

It provides GraphQL on HTTP middleware that can be embedded in any server.

Essentially, it takes a Request object and returns a Response object.

In the meantime, it performs HTTP request validation, processes GraphQL, and response object with the appropriate status code and message.

There is also a built-in GraphQL Playground.

Example

A simple example of creating a GraphQL server.

std/http + grpahql.js

import { graphqlHttp } from "https://deno.land/x/graphql_http@$VERSION/mod.ts";
import {
  Handler,
  serve,
  Status,
} from "https://deno.land/std@$VERSION/http/mod.ts";
import { buildSchema } from "https://esm.sh/graphql@$VERSION";

const schema = `type Query {
  hello: String!
}
`;
const graphqlResponse = graphqlHttp({
  schema: buildSchema(schema),
  rootValue: {
    hello: () => "world",
  },
  playground: true,
});

const handler: Handler = (req) => {
  const { pathname } = new URL(req.url);
  if (pathname === "/graphql") {
    return graphqlResponse(req);
  }

  return new Response("Not Found", {
    status: Status.NotFound,
  });
};

serve(handler);

Spec

This project is implemented in accordance with GraphQL over HTTP Spec.

Request Parameters

A GraphQL-over-HTTP request is formed of the following parameters:

Response Status

The following responses may be returned.

Below are the specific conditions under which each may occur. Errors are classified into four major categories.

• HTTP Request errors
• (GraphQL) Request errors
• (GraphQL) Field errors
• Unknown errors

HTTP Request errors

HTTP Request errors are errors in the http protocol. This refers to errors that can occur between HTTP and GraphQL, such as missing/incorrect values for required parameters, missing/incorrect values for required headers, etc.

Since these are client-side errors, the appropriate 4XX status is returned.

Request errors

Request errors are defined at [GraphQL Spec] 7.Response - Request errors.

Note here that the status code may be different depending on the Content-Type.

application/json

If Content-Type is application/json, all results of GraphQL Requests including GraphQL validation will be treated as 200 status.

See the [GraphQL over HTTP 6.4.1] application/json#Note for the reason for this.

application/graphql+json

If Content-Type is application/graphql+json, it is possible to respond with a status code other than 200 depending on the result of the GraphQL Request.

If the GraphQL request is invalid (e.g. it is malformed, or does not pass validation) then the response with 400 status code.

Field errors

Field errors are defined at [GraphQL Spec 7.Response] - Field errors.

Even if a Field error occurs, it will always be a 200 status code.

Unknown errors

If an error other than the above occurs on the server side, a 500 status code will be responded.

Upgrade to application/graphql+json

As you may have noticed, application/graphql+json represents a more accurate semantics response.

If you want application/graphql+json content, you must put application/graphql+json as a higher priority than application/json in the Accept header.

Example: Accept: application/graphql+json,application/json.

Overwrite response

grpahqlHttp creates a response according to the GraphQL over HTTP specification. You can customize this response.

Example of adding a header:

import { graphqlHttp } from "https://deno.land/x/graphql_http@$VERSION/mod.ts";
import { buildSchema } from "https://esm.sh/graphql@$VERSION";

const responser = graphqlHttp({
  response: (res, ctx) => {
    if (ctx.request.method === "GET") {
      res.headers.set("Cache-Control", "max-age=604800");
    }
    return res;
  },
  schema: buildSchema(`type Query {
    hello: String
  }`),
});

License

Copyright © 2022-present TomokiMiyauci.

Released under the MIT license