Serverless - Running an Express instance in a Lambda function, good or bad?

Question

While learning the Serverless Framework I came across several tutorials showing how to run an Express instance in a Lambda. This seems to me like an overkill and against the purpose of Lambda functions.

The approach usually involves running an Express instance in the Lambda and proxying API Gateway requests to the Express router for internal handling.

To me the trivial approach is to just create an API in API Gateway and route individual requests to a Lambda for handling. Am I missing something?

Taking into account that Lambdas' execution time is 15 minutes, isn't just spinning up the Express instance quite expensive in terms of memory? Also, limited to 100 concurrent Lambda executions would create a bottleneck, no? Wouldn't an EC2 instance be a better fit in such case? Using a Lambda like this seems like an overkill.

The only two benefits I see in running an Express instance in a Lambda are:

1. In the case of migration of an existing app written in Express, allows to slowly break down the app into API Gateway endpoints.
2. Internal handling of routing rather than relying on the API Gateway request/response model (proxying to Express router).

What would be the benefit of such approach, in case I am missing something?

Some resources promoting this approach:

• Express.js and AWS Lambda — a serverless love story (Slobodan Stojanović, freeCodeCamp)
• awslabs/aws-serverless-express (GitHub)
• Deploy a REST API using Serverless, Express and Node.js (Alex DeBrie, Serverless Framework Blog)

Answer 1

Most of your points are valid, and it can indeed be called an antipattern to run Express inside your Lambda functions behind an API Gateway.

Should be noted that the initialization time is not that much of a concern. While the execution time of a single invocation is capped at 15 minutes, a single Lambda instance will serve multiple requests after it has been fired up. A frequently invoked single Lambda instance has usually a lifetime or 6 to 9 hours, and is disposed of at about 30 minutes of inactivity. (note that AWS does not publicly disclose these parameters and these figures should only be used as a ballpark). Whoever is the unlucky one to get the cold start and eat the initialization delay could get an additional delay in the thousands of milliseconds however.

The singular main advantage of this approach is, as you said, providing a migration path for existing Node developers with existing Express knowledge and applications. You should generally not consider this approach when developing an application from scratch and implement idiomatic serverless patterns instead (e.g. utilizing API Gateway routing).

Just to reiterate, the main downsides of this approach:

• Higher needless overall code complexity due to forgoing API Gateway functionality (routing etc.)
• Higher initialization time resulting in longer cold starts
• Larger code footprint due to more dependencies
• Larger code footprint due to losing tree shaking / individual packaging due to internal routing

P.S. The main contender these days probably wouldn't be a dedicated EC2 instance, and rather Fargate containers running Express in Node.js. This pattern has many of the same benefits as Serverless while keeping existing development patterns and tools largely intact.