graphql/yoga-server/docs/integrations/integration-with-aws-lambda

[giscus[bot]]

graphql/yoga-server/docs/integrations/integration-with-aws-lambda

AWS Lambda is a serverless computing platform that makes it easy to build applications that run on the AWS cloud. GraphQL Yoga is platform agnostic so they can fit together easily.

https://the-guild.dev/graphql/yoga-server/docs/integrations/integration-with-aws-lambda

[garfieldnate]

AWS API Gateway does not support multipart/mixed responses, so this setup does not work with defer/stream. Some guidance in this regard would be very helpful.

[n1ru4l]

Supporting streaming responses, should be supported according to this blog post.

That would require updating the example shown on this page. Can you help us verifying whether this works and send a pull request to update the documentation once verified?

[garfieldnate]

We did get it working! I'm sorry, I don't have the resources to fully update the docs, but I'll comment here with what we had to change:

1. We are using yoga as a middleware in Express. No Express configuration changes were required at all; multipart responses just worked out of the box.
2. When creating the Yoga server, we needed to add the useDeferStream plugin:

import { useDeferStream } from "@graphql-yoga/plugin-defer-stream";
export const server = createYoga({
  ...
  plugins: [
    useDeferStream(),
    ...
  ]
  ...
});

3. The AWS handler API for a streaming response is different, so you need to change your handler accordingly in order to connect the yoga and AWS APIs. We went with https://github.com/H4ad/serverless-adapter because it worked (though we're not sure we needed it). Here's some usable code:

// Translation layer from Express to AWS Lambda's handler API
import {
  ServerlessAdapter,
} from "@h4ad/serverless-adapter";
import {
  AwsStreamHandler,
} from "@h4ad/serverless-adapter/lib/handlers/aws";
import { DummyResolver } from "@h4ad/serverless-adapter/lib/resolvers/dummy";
import { ApiGatewayV2Adapter } from "@h4ad/serverless-adapter/lib/adapters/aws";
import { ExpressFramework } from "@h4ad/serverless-adapter/lib/frameworks/express";
import { app } from "./";

export const handler = ServerlessAdapter.new(app)
.setHandler(new AwsStreamHandler())
  // .setLogger(createDefaultLogger({ level: "debug" }))
  .setFramework(new ExpressFramework())
  // for aws url streaming
  // no resolver needed for streaming, resolver = returning data back to AWS.
  // in this case we just write to a stream
  .setResolver(new DummyResolver())
  // Badly named; we are using URL-type functions (no API Gateway!)
  // Necessary because we support GQL defer/stream, which requires streaming support in lambda. See:
  // https://aws.amazon.com/blogs/compute/introducing-aws-lambda-response-streaming/
  .addAdapter(new ApiGatewayV2Adapter())
  .build();

We also filed H4ad/serverless-adapter#264 for documentation purposes, just showing how to set the AWS context fields if users need that.
4. As detailed in the article you shared, the Lambda function must not be behind AWS's API Gateway. Instead, it should called by URL. We use the Serverless framework to set up our functions, and the configuration there looks like this:

functions:
  graphqlServer:
    handler: src/index.handler
    url:
      # critical to allowing streamed responses to the user, currently used for GQL defer/stream
      # must be a URL function; not supported on API Gateway
      invokeMode: RESPONSE_STREAM

5. Our resolver functions are already async, so we are able to use @defer with them immediately. We have not tried @stream yet, but I believe it would require changing a resolver method to be an AsyncGenerator (so each piece of data to stream to the user would be sent via a yield call).