Use callback instead of context.succeed

[lopezjurip]

This is not compatible with https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-handler.html neither Serverless (serverless/serverless#2379)

[brettstack]

During tests, I found that using context.succeed was more performant than using callback. This is because callback waits for the event loop to be empty, which doesn't happen with Express server always listening. There is the context.callbackWaitsForEmptyEventLoop option documented here http://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html, however I have not tested/profiled using this.

[dinvlad]

A bit off-topic, but is context.succeed API deprecated, or can we still rely on it for the foreseeable future? If it is, then are there any breaking changes that we should expect for aws-serverless-express in this regard?

[brettstack]

This will be supported for the foreseeable future. Even if it did go away, the change on your end will be as simple as passing through the `callback` to the proxy.

…

On Thu, May 11, 2017, 3:29 PM Denis Loginov ***@***.***> wrote: A bit off-topic, but is context.succeed API deprecated, or can we still rely on it for the foreseeable future? If it is, then are there any breaking changes that we should expect for aws-serverless-express in this regard? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABy6l8uUuKbcWFSBo-IlfKKm56tUSqrmks5r44vTgaJpZM4LNW3X> .

[chrisfinch]

Hi all,

Wondering if there has been any movement on this? I currently have a usecase where I would like to run an aws-serverless-express application under a single serverless lambda function. It seems that the lack of callback creates an incompatibility between the two.

Any advice would be helpful - I'd like to avoid having to split out the two applications if possible.

[geovanisouza92]

@chrisfinch You could provide a fake context, it works nice.

[mgmarino]

Hi all,

a few things:

• Are we sure this will be around for a long time? AWS has it in their documentation here that requests to continue using node v0.10 must come before June 30, 2017, perhaps this also means these functions will be removed soon thereafter for node lambda functions version > 4.x.

• We have a use case where we need to wait for the run-loop to clear. Our work around (not sure if this is applicable to your use case, @chrisfinch?) is:

export function handler(lambdaEvent: any, context: lambda.Context, callback: Callback) {
    try {
        const server = awsServerlessExpress.createServer(app);
        context.succeed = (response) => {
            server.close();
            callback(null, response);
        };
        return awsServerlessExpress.proxy(server, lambdaEvent, context);
    } catch (error) {
        // ...
    }

where we actively stop the server so that the lambda function doesn't hang after the other entries in the run loop have resolved. I haven't seen any significant performance difference between doing this and letting the server "run", but YMMV.

• It would be really nice to not have to start a http server inside of a lambda, would it not be possible to call express directly with request/response objects (e.g. app.handle(req, res);)? I understand this has other complexities, but I think it would make the behavior inside of the lambda better (e.g. no long-running code that needs to be paused). Perhaps something for another issue.

[chrisfinch]

@geovanisouza92 @mgmarino Thankyou both - very helpful - I'll give the fake context a try.

[chrisfinch]

@geovanisouza92 @mgmarino Perhaps you could help me further if possible. I seem to be missing a part of the puzzle or my understanding is lacking.

I'm getting ERR_CONTENT_DECODING_FAILED in my browser which according to the commented code is related to binary mime types not being handled correctly by serverless. I'm trying to run it locally at the moment with serverless-offline.

I'm also getting a lot of the following warnings from serverless which may or may not be related:

WARNING: Attempting to listen on socket /tmp/server0.sock, but it is already in use. This is likely as a result of a previous invocation error or timeout. Check the logs for the invocation(s) immediately prior to this for root cause, and consider increasing the timeout and/or cpu/memory allocation if this is purely as a result of a timeout. aws-serverless-express will restart the Node.js server listening on a new port and continue with this request.

Here's an excerpt from my serverless.yml

  express:
    handler: server/express/express.handler
    timeout: 300
    events:
    - http:
        path: /express/{proxy+}
        method: ANY

And here's the handler code using aws-express-serverless

'use strict'
const awsServerlessExpress = require('aws-serverless-express')
const app = require('./app')

// NOTE: If you get ERR_CONTENT_DECODING_FAILED in your browser, this is likely
// due to a compressed response (e.g. gzip) which has not been handled correctly
// by aws-serverless-express and/or API Gateway. Add the necessary MIME types to
// binaryMimeTypes below, then redeploy (`npm run package-deploy`)
const binaryMimeTypes = [
	'application/javascript',
	'application/json',
	'application/octet-stream',
	'application/xml',
	'font/eot',
	'font/opentype',
	'font/otf',
	'image/jpeg',
	'image/png',
	'image/svg+xml',
	'text/comma-separated-values',
	'text/css',
	'text/html',
	'text/javascript',
	'text/plain',
	'text/text',
	'text/xml'
]

exports.handler = (lambdaEvent, context, callback) => {
    try {
        const server = awsServerlessExpress.createServer(app, null, binaryMimeTypes);
        context.succeed = (response) => {
            server.close();
			console.log(response);
			callback(null, response);
        };
        return awsServerlessExpress.proxy(server, lambdaEvent, context);
    } catch (error) {
        // ...
    }
}

Could either of you give me any pointers? Many thanks in advance!

[dinvlad]

The sock warning is likely because you start a new server on every request. You should only do that once outside of your Lambda, so it will be 'warm' on the next request, as suggested earlier by @brettstack

Binary support currently requires quite a few tweaks, both on the server and the client side (incl. you have to send an Accept header that starts with one of your binary types). It may be worth for you to enable */* to simplify things. That is not specific to aws-serverless-express I'm afraid.

[mgmarino]

The workaround with stopping the stopping/starting the server was necessary for our use case because we needed the event loop to be cleared. @chrisfinch if you don't need this, you can move the server instantiation out, but if you do this you will need to set:

context.callbackWaitsForEmptyEventLoop = false;

at least for running in lambda.

[brettstack]

I assume you're getting ERR_CONTENT_DECODING_FAILED locally because serverless-offline doesn't convert Base64 to binary for you. Try removing all the binary mime types (at least for local).

[brettstack]

If anyone wants to provide benchmarks with callback and context.callbackWaitsForEmptyEventLoop I'd be happy to move over to that.

[brettstack]

@chrisfinch can you elaborate

I currently have a usecase where I would like to run an aws-serverless-express application under a single serverless lambda function. It seems that the lack of callback creates an incompatibility between the two.

[brettstack]

As mentioned by @dinvlad I strongly advise against awsServerlessExpress.createServer inside your handler for performance reasons.