Lambda layers with NodeJS
Why Lambda layers
When developing nodeJS microservices applications in AWS most of the time developers need to share common libraries between micro services. Re-writing those common libraries or importing those common libraries into every microservice, will increase file size of the lambda function and slow down the deployment process. As a solution developers can use lambda layers.
Lambda layers are very useful for sharing code between lambda functions, which is a zip archive that can contain additional codes, such as libraries and dependencies. By moving dependencies or libraries from your function code to a layer, it reduces the overall size of the archive uploaded during a deployment. Developers can include up to five layers per function. By default lambda layers are private but developers can share it with other AWS accounts or can make it public.
Lambda layers are immutable and can be versioned to manage updates. When a version is deleted or permissions to use it are revoked, functions that used it previously will continue to work, but you won’t be able to create new ones.
The storage of lambda layers takes part in the AWS Lambda function storage per region limit which is 75GB.
Benefits of lambda layers
- Keep the size of deployments small.
- Each lambda function can have the code only specific to the action it is intended to perform.
- Single package for all shared dependencies. No need to package shared dependencies with your lambda functions. Instead, create a layer and reuse it with different functions.
- Easier code updates. If the common dependencies are managed in the layers, then updating the dependency is very easy, as you only need to update the layer in which the dependency is packaged.
Lambda Layer Permissions
Layers can be used within
- An AWS account
- Shared between accounts
- Shared publicly with the broad developer community
Simple guide to lambda layers
In this example I am going to create a lambda layer for a simple response helper so that we can use that response helper layer in all our services without implementing it individually in every service.
First we have to create a serverless project using sls create -t node-js. Then in nodeJS we have to create a folder structure as per the image below.
Then within the response-helper directory you have to initialize a npm module by using npm init.
Afterwards you have to create an index.js file in the response-helper directory and you have to write your response helper logic there and you have to export it.
In the serverless.yml file under the layers you have to define your response helper and you have to specify the path.
Once everything is properly configured you have to deploy the service by using sls deploy. After you deploy it your lambda layer will display in the layer section in the lambda function service.
Once you go into the layer section you can see your lambda layer with a version number 1. When you do any changes in your lambda layer and re-deploy your version number will increase accordingly.
In the cloudformation now you can see the stack of the lambda layer.
In the stack in the output section you can see the qualifiedarn of your lambda layer. You can reference that in your lambda functions now.
To add a lambda layer to your handler function, under the layers section you have to reference the lambda layer’s qualified arn as per the below image.
To import the response helper into your service handler function, you have to import it as you normally import a javascript module.
Once you do everything properly and you invoke your API using an API client you can get your desired response as shown below.
Limitations of lambda layers
- A Lambda function can use up to five layers.
- The maximum size of the total unzipped function and all layers is 250 MB.
References
- Creating and sharing Lambda layers www.docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html
- Using Lambda layers to simplify your development process www.aws.amazon.com/blogs/compute/using-lambda-layers-to-simplify-your-development-process/
Thivanka Nimesh
Software Engineer
Why Lambda layers
When developing nodeJS microservices applications in AWS most of the time developers need to share common libraries between micro services. Re-writing those common libraries or importing those common libraries into every microservice, will increase file size of the lambda function and slow down the deployment process. As a solution developers can use lambda layers.
Lambda layers are very useful for sharing code between lambda functions, which is a zip archive that can contain additional codes, such as libraries and dependencies. By moving dependencies or libraries from your function code to a layer, it reduces the overall size of the archive uploaded during a deployment. Developers can include up to five layers per function. By default lambda layers are private but developers can share it with other AWS accounts or can make it public.
Lambda layers are immutable and can be versioned to manage updates. When a version is deleted or permissions to use it are revoked, functions that used it previously will continue to work, but you won’t be able to create new ones.
The storage of lambda layers takes part in the AWS Lambda function storage per region limit which is 75GB.
Benefits of lambda layers
- Keep the size of deployments small.
- Each lambda function can have the code only specific to the action it is intended to perform.
- Single package for all shared dependencies. No need to package shared dependencies with your lambda functions. Instead, create a layer and reuse it with different functions.
- Easier code updates. If the common dependencies are managed in the layers, then updating the dependency is very easy, as you only need to update the layer in which the dependency is packaged.
Lambda Layer Permissions
Layers can be used within
- An AWS account
- Shared between accounts
- Shared publicly with the broad developer community
Simple guide to lambda layers
In this example I am going to create a lambda layer for a simple response helper so that we can use that response helper layer in all our services without implementing it individually in every service.
First we have to create a serverless project using sls create -t node-js. Then in nodeJS we have to create a folder structure as per the image below.
Then within the response-helper directory you have to initialize a npm module by using npm init.
Afterwards you have to create an index.js file in the response-helper directory and you have to write your response helper logic there and you have to export it.
In the serverless.yml file under the layers you have to define your response helper and you have to specify the path.
Once everything is properly configured you have to deploy the service by using sls deploy. After you deploy it your lambda layer will display in the layer section in the lambda function service.
Once you go into the layer section you can see your lambda layer with a version number 1. When you do any changes in your lambda layer and re-deploy your version number will increase accordingly.
In the cloudformation now you can see the stack of the lambda layer.
In the stack in the output section you can see the qualifiedarn of your lambda layer. You can reference that in your lambda functions now.
To add a lambda layer to your handler function, under the layers section you have to reference the lambda layer’s qualified arn as per the below image.
To import the response helper into your service handler function, you have to import it as you normally import a javascript module.
Once you do everything properly and you invoke your API using an API client you can get your desired response as shown below.
Limitations of lambda layers
- A Lambda function can use up to five layers.
- The maximum size of the total unzipped function and all layers is 250 MB.
References
- Creating and sharing Lambda layers www.docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html
- Using Lambda layers to simplify your development process www.aws.amazon.com/blogs/compute/using-lambda-layers-to-simplify-your-development-process/
Thivanka Nimesh
Software EngineerDeveloping a Custom Audit Trail and a Notification Service for a Workflow Based Serverless Application on AWS
READ ARTICLE
Human Emotions Recognition through Facial Expressions and Sentiment Analysis for Emotionally Aware Deep Learning Models
READ ARTICLE