CODEWITHSUNDEEP
amazon-web-servicesapiaws-lambdaapi-design
9er
9er

Reputation: 1734

Is it better to have 1 Lambda function per route? or 1 Lambda that handles child routes?

If I have an API that has the following routes

POST /slack
POST /slack/hook
POST /slack/another-hook
POST /slack/hook/nested

Is it better to have 4 separate Lambda functions and 4 routes in the API Gateway? Or to have 1 Lambda for the root route and have the Lambda handle the routing from there?

example 1

POST /slack --> lambda1
POST /slack/hook --> lambda2
POST /slack/another-hook --> lambda3
POST /slack/hook/nested --> lambda4

example 2

POST /slack --> lambda1
POST /slack/hook --> lambda1
POST /slack/another-hook --> lambda1
POST /slack/hook/nested --> lambda1

Is there a best practice for this? If so why?

Upvotes: 23

Views: 7387

Answers (3)

berimbolo
berimbolo

Reputation: 3869

I have been debating this and opted for separate git repositories per service, for example person, account etc and each with its own lamba functions.

This allows me to treat each repo/serverless project as its own microservice and I use the MVC pattern of a controller with services and a DAO per microservice.

My pipelines build and test single repos, deploy and then run system integration tests on single repos.

What I didn't like about the router pattern were:

  • Logging of functions, single log stream

  • Single point of failure

  • Regression with every change

  • I prefer discrete separation of concerns

  • Testability

  • You now need to cater for your hungriest lambda, e.g it requires 1024mb ram, a simple GET could suffice with 128mb or now you need to start breaking your pattern and refactoring as you need to move functions around

  • I read a few articles which demonstrate that the return you get on cold start is really only applicable when you have under utilised endpoints

I used a serverless plugin to warm lambdas as the only real benefit (imo) of the router pattern is less cold starts.

Upvotes: 1

user818510
user818510

Reputation: 3652

This blog post here explains the pros and cons of various serverless patterns. Following are some things to keep in mind:

One Lambda per route aka microservice pattern:

Pros

  • Easier to debug since each lambda has a very specific function and cloudwatch logs are well separated.
  • Easier to test since each lambda handles a separate event.
  • Deployments are more fine grained. Updating a function can only affect a specific functionality so you have a separation of concerns.

Cons

  • Possibly more cold starts for lambdas since some of them might not be frequently accessed.

  • You might end up with a lot of lambda functions to manage.

  • Slower deployments as there are multiple functions to deploy.
  • You might run into the cloudformation resource limit for a single stack(which is 200 resources) pretty soon. I have run into this personally.

One Lambda with multiple routes aka service/monolith pattern depending how routes are grouped:

Pros

  • Fewer cold starts/better performance since the lambda would be invoked frequently and stay warm.
  • Fewer lambda functions to manage.
  • Faster deployments as there are fewer functions to deploy.

Cons

  • Harder to debug and analyse cloudwatch logs, function handles multiple types of events.
  • You need to write and maintain a router.
  • Bigger function size so you could hit the deployment size limit.
  • Updating a function might cause regression and break some other functionality.

As you can see, there are pros and cons to each approach and there is no single right way to do things. Also as the other answer suggests, you need to consider things like CICD, project and time constraints as well.

Upvotes: 21

b.b3rn4rd
b.b3rn4rd

Reputation: 8840

I will be surprised if anyone says that there is a right and wrong answer.

I've done both in different projects, I guess it comes down to the CICD preferences, architecture, time constraints.

Having one lambda theoretically simplifies your architecture but effectively you're building a monolithic app with all the downsides applicable to that architecture, however, if you're single dev it significantly minimises building, testing and deployment process, so you don't have to worry about dependencies between lambdas and have a single deployable artifact.

On the other hand, multiple lambda functions offer you the flexibility similar to microservices, but it would require you to have individual pipelines and the whole CICD ecosystem becomes more complex and time-consuming.

On more thing to be mindful when having all code in one lambda function, is the size limit and potential dependency hell, depending on your language.

Not knowing your organisation/project and time constraints, I would probably start with a single lambda and split it into multiple lambda functions later if needed...

Upvotes: 7

Related Questions