Duplicate Lambda

Serverless Framework
1

I’m fairly new to AWS and serverless in general so trying to get a feel for how it all works and how best to structure my project.

I followed this example layout for using a single lambda function for all CRUD operations with the serverless.yaml using the same file but different method. https://github.com/pmuens/serverless-crud

I assumed this would create 4 API paths all pointing to the single lambda function which I figured is good for reducing cold starts and simplifying my code layout. However, it created 4 duplicate lambda functions with different names.

I am just wondering if this is expected behaviour or if I have done something wrong?

2

just to add to this, as another test I changed the layout of my project to be the following to try to separate out the logic into individual lambda functions
itemsendpoint
----|–functions
--------|–getAll
------------|–handler.js (containing just the code to get all items)
--------|–getSingle
------------|–handler.js (containing just the code to get single item)
----|–templates (folder containing relevant vtl templates)
----|–serverless.yml

My serverless.yml references the handler like handler: functions/getAll/handler.listAll

But now the lambdas are still duplicated and both contain the entire functions folder and the templates folder.

Have I got a fundamental misunderstanding here or doing something silly?

3

Latest update. Using a SAM template you can specify the path of the code for your lambda function using the CodeUri entry in your yaml file but it doesn’t appear that this is supported in the serverless framework.

I like the simplicity of the serverless framework but not having control of things like this is pushing me back towards using SAM.

PostPetFunction:
Type: AWS::Serverless::Function
Properties:
  FunctionName: PostPetFunction
  Runtime: python3.6
  Handler: function.handler
  CodeUri: ./lambda/postPet/
  Events:
    PostPetApi:
      Type: Api
      Properties:
        RestApiId: !Ref "PetStoreApiGateway"
        Path: /pet
        Method: POST
4

Looking at that project (which is rather old done in 2016) it will create several different lambda functions for each part which is a “function”. It should not create duplicate lambda functions, if that happened then something is wrong. The problem might be that the version of nodejs you try to use is being deprecated and obsolete https://aws.amazon.com/blogs/developer/node-js-6-is-approaching-end-of-life-upgrade-your-aws-lambda-functions-to-the-node-js-10-lts/

But I suggest that you use some newer example preferably directly from the serverless blog or repository instead. https://github.com/serverless/examples

If you still prefer a nodejs backend then there are examples at the above link.

5

Hi,

Many thanks for the reply. I have tried increasing the node version but that didn’t help with the duplication of lambda functions.

I took a look at the examples you mentioned and deployed the serverless-rest-api-with-dynamodb example as that has multiple lambdas but that also duplicates the lambdas and has all of the handler files uploaded to each lamba as seen in the picture below. Is that what you would expect to see?

Capture
Capture1665×831 76.7 KB

6

The functions are unique in that the serverless-rest-api-with-dynamodb-dev-get is a single Function.
The part that appears to be confusing you is that ALL the code from your project is deployed into all four Lambda functions.
This is normal behavior.

If you wish to only include the code relevant to each function, you need to configure your serverless.yml to individual package your functions. See The Serverless Docs for Individual function packages for more details.

Or you Webpack & the serverless-webpack plugin to do tree-shaking and reduce each functions footprint even more.

7

Ahh! Awesome! Many thanks for your reply. The package - individually and then using package -exclude has given me the result I want which is that only the relevant files get uploaded to my Lambda function.

Out of interest, you say that deploying ALL the code into all Lamda functions is normal behaviour. Is that just because its too hard to figure out what is needed without the developer explicitly stating that or is there some other use case that I am missing where this is actually beneficial?

Thanks again

8

I imagine it’s just legacy behavior. There are times when letting the system try and work that out fails, so the default behavior, while not optimal in regards to deployment package/lambda size, is likely the safest path to ensure that all necessary files are included. Thus it’s remained as the default.

But thankfully, the tools have been added over time to enable developers to optimize to their hearts content.

9

yeah that makes a lot of sense. Thanks again