Support AWS Lambda

[samin]

It's hard to use the actual processRequest for Lambda because it does not give me a request, response model to follow to write a middleware. I've rewritten it to accept an event given in
exports.handler = async (event, context) => {}

https://gist.github.com/samin/976271f97b03bba14017a760570df88a

Would it be possible to add it?

[jaydenseric]

Since AWS will gather the whole request in memory before passing it on to your function, any workarounds to try to simulate a request stream for processRequest which then buffers it to "disk" all over again via fs-capacitor would be a performance tragedy.

For propper AWS Lambda support we could publish a function that processes an event into something that can be passed into existing GraphQL handlers, without using fs-capacitor. It would read the GraphQL multipart request form data (Base64?) string provided in the Lambda event, and extract the files and query and variables, putting them together to look like a regular GraphQL POST request for popular GraphQL handlers (e.g. apollo-server-lambda) to consume.

I haven't thought a lot about the details, and don't plan to work on it personally anytime soon as I don't have a need for it for any of my work or personal projects. I prefer to process file uploads as the stream in, for a much faster response time:

https://github.com/jaydenseric/graphql-multipart-request-spec/blob/master/sync-vs-async-graphql-multipart-request-middleware.svg

A function for Lambda should actually be a much simpler implementation that the current processRequest implementation for HTTP requests that stream in, because you can tell up front if the form data is malformed or not and you know all the files are there; you don't have to handle all the problems of expected files never arriving, disconnects part way through, multiple resolvers consuming the same file streams etc.

The GraphQL upload scalar promise in a serverless environment could resolve the same file upload details, except instead of createReadStream there would be base64FileContents (name can be polished).

[mike-marcacci]

I 100% agree that because the current implementation is so highly optimized for the case of streaming data, it would be a total disaster to try and use it for data that is already in memory.

However, for the sake of maintaining the portability of users' resolvers, it might be best to retain the same API as this library (that with a promise which resolves metadata and a createReadStream method). The created streams would simply read from the corresponding file's Buffer and have nothing to do with the filesystem or fs-capcitor. While these extra hoops wouldn't strictly be necessary, they would have almost no performance penalty (assuming the resolver actually uses the stream as a stream and doesn't immediately try to concat it back into a new in-memory string/Buffer) and would allow the same resolvers to be usable in both a HTTP server and a lambda/google function.

I think this would be fairly trivial to write, although like you I have neither need for this at the moment, nor the time to actually do it.

[koresar]

Hi @samin

I've recently forked this awesome package and added AWS Lambda support. I need someone to test it.
Is there anyone out there who'd like to report if this works?

https://www.npmjs.com/package/graphql-upload-minimal/v/1.1.0-0#aws-lambda

TL;DR:

• Replace graphql-upload with graphql-upload-minimal@next
• Test if it works for you.
• Put a comment here that it work (or not).

[vaunus]

FYI after going down a rabbit hole with this, graphql-upload seems to be working nicely with Apollo v3 on lambda out of the box. We are using the Express middleware method for setting up the server - I guess @vendia/serverless-express which apollo-server-lambda now uses is helping put the request object into the correct format.

[federicobarera]

@vaunus , incidentally I was looking at it today. When you say

We are using the Express middleware method for setting up the server

What do you mean?

[vaunus]

@federicobarera sorry I meant we're setting the Apollo handler up like this:

const handler = apolloServer.createHandler({
  expressAppFromMiddleware(middleware) {
    const app = express()
    app.use(graphqlUploadExpress())
    app.use(middleware)
    return app
  }
})

In Apollo v3 the above is all that is required for graphql-upload to work in a lambda.