Why to re-route within a lambda?

[ugurcemozturk]

Hi, My question is basically about the motivation to use routing within a lambda.

Since one should apply the routing in gateway layer. When you migrate this logic to lambda, what is the purpose of Api Gateway?

For more than many cases, Api Gateway should take care the routing and request forwarding to lambdas since they are/should be the 'endpoints' with a single purpose.

I'm very willing the hear gotchas if I miss sth

Cheers!

[jeremydaly]

Hi @ugurcemozturk! Lambda API let’s you take multiple approaches, e.g. single purpose functions, lambdalith with multiple routes, or a combination. This package gives you a familiar express-like interface with a number of convenience methods to make writing API functions easier.

[VincentClair]

Hi ! Here we group operations by resources : ANY method on resource A is handled by one handler. Lambda API take the hand to re-route event by method or url.

Example :

• GET /companies/{id}/users and POST /users are handled by the same lambda : Lambda API routes to each dedicated "sub" handlers.
• GET /companies on another lambda

[Sleavely]

A subtle but important benefit at scale is that when you point multiple API Gateway routes to the same Lambda you can cache things in-memory, such as your database connection.

Consider this: If you have a lot of requests for /product/{id} but not so many requests to /checkout, the checkout lambda would have to boot up (cold start) and establish database connections more often, causing the checkout process to appear slower than the rest of the site. If you point both endpoints to the same lambda it's more likely that there's already an available & booted lambda ready to process the checkout request.

You can still use API Gateway to specify required parameters on individual routes so that you don't have to perform that type of basic validation in your code. If you deploy your API Gateway through an OpenAPI specification, you also get documentation that corresponds to exactly what is deployed. I've used this pattern in a lot of projects, including geja-cloud which is on Github.

On the other hand, if you have a lot of different functionality on each endpoint you may not see the same synergy effect, and it can contribute to making your codebase hard to follow - in those cases it may be better to split it into smaller separate lambdas. As always, it depends on your individual needs and preferences. :)

[davthedev]

There is a cost in managing multiple lambdas that would hit the same data source. If you share code between the different lambdas, that part would need to be packaged into a Lambda layer to avoid code duplication. Maintaining such a layer seems to add significant complexity.

This is the case if you use a SQL database and an ORM such as Sequelize to abstract access to it. The entities configuration needs to be shared and packaged into a layer. Each time you need to touch that configuration, you would need to update the layer and propagate it to all lambdas that are developed against it. AFAIK, that process is not straightforward and would slow the development process.

[farqis]

With many real-life projects you will very soon hit resources limit (500) on cloud formation stack if you try to create individual lambda functions for every end-point. (The limit used to be 200 until recently!)

Introducing routers enables you to combine them into a few lambdas only, thus reducing the number of resources, and resolving cold-start issues as well.

[dolsem]

@ugurcemozturk if you feel like single route functions fit your goals better, check out my fork - I'd love feedback on it! https://github.com/dolsem/simple-lambda-api