AWS Lambda support

[jtmthf]

I've been prototyping an API to use with AWS Lambda and this is a basic example of what it could look like:

import { GraphQLLambda } from 'graphql-yoga';

const typeDefs = `
    type Query {
        hello(name: String): String!
    }
`;

const resolvers = {
    Query: {
        hello: (_, { name}) => `Hello ${name || 'World'}`,
    },
}

const handler = new GraphQLLambda({ typeDefs, resolvers });

export const graphql = handler.graphql;
export const playground = handler.playground;

The implementation would be simple to put together for basic use cases, but subscriptions and file-upload would be missing. Binary file-upload is possible already with AWS lambda through API gateway, but if you're using serverless framework (which I imagine most people are), it doesn't currently support it as a configuration option. I'll likely open an issue with serverless to add binary pass-through as an option. Following that, apollo-upload-server would also need lambda support, but that is a trivial addition that I can do.

Subscriptions are the one feature that cannot be entirely handled in lambda. What works instead is having a separate subscription server using express graphql-yoga or some other http server with websocket support and then use remoteSchemaStitching to then have the subscription server resolve queries through the lambda interface.

Looking for some feedback on this approach before anything gets implemented. Thanks!

[jtmthf]

Good news on the serverless front for file uploads. There is already a serverless plugin for allowing binary types maciejtreder/serverless-apigw-binary. There is already an issue in serverless/serverless#2797, for enabling it in core, but a plugin works for now. This leaves apollo-upload-server the only blocker for adding file upload support in lambda.

[chrisl777]

@jtmthf Do you have a branch where we can look at the code in your GraphQLLambda approach?

[schickling]

The suggested API looks really nice and clean. I like it @jtmthf!
I think it's fine that for now file-upload & subscriptions don't work yet. This can be added later!

Would be great if you could create a PR for this? 👍

[jtmthf]

@chrisl777 @schickling I don't have an implementation yet, but I will be putting it together this weekend with a PR.

I did run into one issue that would be problematic with the current API. As Lambda requires the handler to be provided synchronously as a module export, the schema cannot be created asynchronously. One common case of this is introspecting a graph.cool backend. To resolve this in a prior project of mine, I did this in the entry:

import {
  graphqlLambda,
  LambdaGraphQLOptionsFunction
} from "apollo-server-lambda";

import { schema } from './schema';

const optionsFunction: LambdaGraphQLOptionsFunction = async () => {
  return {
    schema: await schema.getSchema()
  };
};

export const graphql = graphqlLambda(optionsFunction);

Where schema is a singleton class instance that caches the schema to prevent re-instrospecting graph.cool on each invocation while the function is warm.

I can leave out this concern in an initial PR, but I think there should be some consideration towards having built-in support for async generated schemas, especially for simple remote schemas.

[schickling]

Would it be an option in that case to read the schema from a file instead? (This is what we're seeing as a emerging best practice.)

[jtmthf]

That would work, or would it be even better to have explicit support for graphql-config? That would be a separate PR of course.

[chrisl777]

Initially, I think in the case of Lambda, it would be great to have support for using a schema string in a local variable, or reading from a local .graphql file. For a Lambda, it is probably better to cache the schema locally, since you get billed for execution time.

Then, later on, you could add support for graphql-config, for the more intensive cases that people may have.

[kbrandwijk]

One of the additional issues with Lambda is the websockets support. Lambda is not designed for long-lived connections, so as much as I'd like to see yoga deployed to AWS Lambda, I don't know if it's a good fit altogether...

[kbrandwijk]

Lambda support is released in v0.9.0.

[fgiarritiello]

@kbrandwijk how is websocket going to work on a lambda?

[schickling]

Unfortunately websockets are not yet supported via AWS Lambda but I encourage you to look into now as an easy alternative. If you want to stick with AWS you can also host Yoga using containers for example via ECS or Elastic Beanstalk.

[Urigo]

Hey, @Urigo from The Guild here!

You might know us from projects such as graphql-code-generator, envelop or graphql-tools.

For a long time we thought that the Javascript ecosystem is still missing a lightweight cross-platform, but still highly customizable GraphQL Server.

In the past the awesome Prisma team took on that great challenge and now we are happy to announce that we are continuing them and just released GraphQL Yoga 2.0 - Build fast, extensible, and batteries-included (Subscriptions, Serverless, File uploads support) GraphQL APIs in Node.js 🚀

And regarding the issue here, Yoga is completely separated from the way you do HTTP, so you can easily use and expose anything to express but also use Yoga on many other environments and frameworks like Fastify, Cloudflare Workers, Lambdas and many more.

We have been working a long time on version 2.0 and have been using it in our clients projects for a few months now and shared a couple of alpha cycles here.
Thank you all for your feedback and suggestions, you made this release possible!

Please try Yoga out again, give us feedback and help us spread the word on the new release!

• Announcement and blog post
• V2 Roadmap #704
• https://www.graphql-yoga.com/