apollo-server-lambda: remove old callback style #5018
Comments
glasser
added a commit
that referenced
this issue
Mar 11, 2021
Lambda has two ways of defining a handler: as an async Promise-returning function, and as a callback-invoking function. https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html The async variety was introduced with Lambda's Node 8 runtime. Apparently the callback-invoking variety was removed with their Node 14 runtime (their docs don't mention this anywhere but our users have reported this: #1989 (comment)). While AWS doesn't directly support pre-Node-8 runtimes any more, it's possible some users are using a Custom Runtime that still requires the Node 6 version, and Apollo Server still technically supports Node 6. So we would like to support both an async and a callback-invoking handler. To implement this, I rewrote the handler to be an async function and used a little maybeCallbackify function to make it work as either type of handler. (Apollo Server 3 will drop Node 6 support, at which point we should just make this package always return an async handler. Tracking in #5018.) This simplified a lot of the logic and I was able to replace various Promise and callback-y stuff with direct code. To make this easier, I inlined the graphqlLambda function (which was the main API in Apollo Server v1 but is not exported in v2). This makes it easier to avoid bugs like #3999. (We aren't positive if there is actually a Node 14 compatibility issue or not; see #1989 (comment). It's still a helpful refactor though.) Original version by @adikari. Fixes #1989 Co-authored-by: David Glasser <[email protected]>
glasser
added a commit
that referenced
this issue
May 7, 2021
Lambda has two ways of defining a handler: as an async Promise-returning function, and as a callback-invoking function. https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html Until v2.21.2 our handler was only a callback-invoking function. Starting to that version, it could be called in either way. This meant that the TypeScript types for our handler were somewhat vague (see #5072). All current Node Lambda runtimes support calling async functions; the only reason that we didn't just change directly from callback-invoking to async in v2.21.2 was to support the use case of user code that wraps our handler in their own function. But now we're doing AS3 so we can make backwards-incompatible changes, so if you're doing that, you should just make your handler async too and `await` the result of our handler. Fixes #5018.
glasser
added a commit
that referenced
this issue
May 7, 2021
Lambda has two ways of defining a handler: as an async Promise-returning function, and as a callback-invoking function. https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html Until v2.21.2 our handler was only a callback-invoking function. Starting to that version, it could be called in either way. This meant that the TypeScript types for our handler were somewhat vague (see #5072). All current Node Lambda runtimes support calling async functions; the only reason that we didn't just change directly from callback-invoking to async in v2.21.2 was to support the use case of user code that wraps our handler in their own function. But now we're doing AS3 so we can make backwards-incompatible changes, so if you're doing that, you should just make your handler async too and `await` the result of our handler. Fixes #5018.
glasser
added a commit
that referenced
this issue
May 7, 2021
…#5188) Lambda has two ways of defining a handler: as an async Promise-returning function, and as a callback-invoking function. https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html Until v2.21.2 our handler was only a callback-invoking function. Starting to that version, it could be called in either way. This meant that the TypeScript types for our handler were somewhat vague (see #5072). All current Node Lambda runtimes support calling async functions; the only reason that we didn't just change directly from callback-invoking to async in v2.21.2 was to support the use case of user code that wraps our handler in their own function. But now we're doing AS3 so we can make backwards-incompatible changes, so if you're doing that, you should just make your handler async too and `await` the result of our handler. Fixes #5018.
|
Fixed on release-3.0 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
#5004 switches the lambda handler from the old pre-Node-8 callback style to the new async style (the only style allowed with Node 14, apparently) but then wraps it so it works either way via maybeCallbackify. Since AS3 will remove Node 6 support, we can remove the maybeCallbackify in AS3.
The text was updated successfully, but these errors were encountered: