Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lambda body format not recognised when parsed via API Gateway #203

Closed
eurobob opened this issue May 16, 2020 · 1 comment
Closed

Lambda body format not recognised when parsed via API Gateway #203

eurobob opened this issue May 16, 2020 · 1 comment

Comments

@eurobob
Copy link

eurobob commented May 16, 2020

I've been a bit all over the place trying to find the source of this problem.

Ultimately, I had to enable binary media on API Gateway, which works to an extent. It encodes the multipart/form-data into base64. In my apollo server handler I convert it back to a binary string, but it does not seem to be recognised by the busboy parser in the processrequest file.

This is in my index file:

export const handler: APIGatewayProxyHandler = (event, context, callback) => {
  if (Object.keys(event.headers).includes('Content-Type')) {
    event.headers['content-type'] = event.headers['Content-Type']
  }
  if (event.isBase64Encoded && event.body) {
    event.body = Buffer.from(event.body, 'base64').toString('binary')
  }
  const graphql = server.createHandler({
    cors: {
      origin: true,
      credentials: true,
    },
  })
  return graphql(event, context, callback)
}

I get the following error in my logs:

{
    "errorType": "Runtime.UnhandledPromiseRejection",
    "errorMessage": "BadRequestError: Missing multipart field ‘operations’ (https://github.com/jaydenseric/graphql-multipart-request-spec).",
    "reason": [
        {
            "errorType": "BadRequestError",
            "errorMessage": "Missing multipart field ‘operations’ (https://github.com/jaydenseric/graphql-multipart-request-spec).",
            "message": "Missing multipart field ‘operations’ (https://github.com/jaydenseric/graphql-multipart-request-spec).",
            "extensions": {
                "code": "INTERNAL_SERVER_ERROR"
            }
        }
    ],
    "promise": {},
    "stack": [
        "Runtime.UnhandledPromiseRejection: BadRequestError: Missing multipart field ‘operations’ (https://github.com/jaydenseric/graphql-multipart-request-spec).",
        "    at process.<anonymous> (/var/runtime/index.js:35:15)",
        "    at process.emit (events.js:310:20)",
        "    at process.EventEmitter.emit (domain.js:482:12)",
        "    at processPromiseRejections (internal/process/promises.js:209:33)",
        "    at processTicksAndRejections (internal/process/task_queues.js:98:32)"
    ]
}

Am I missing something obvious? I tried doing it without base64 conversion as well but to no avail

@jaydenseric
Copy link
Owner

AWS lambdas are not really suited to processing multipart requests that are meant to be processed in chunks that stream in, especially if you are processing potentially large uploads. You will run into a lot of challenges trying to get it to work, things like memory usage and timeout issues.

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" via fs-capacitor would be a performance tragedy. You'd probably better off implementing file uploads as base64 string mutation arguments.

Track #155 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, and extract the files and query and variables, putting them together to look like a regular GraphQL POST request. I haven't thought a lot about the details, and don't plan to work on it personally as I don't have a need for it for any of my work or personal projects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants