How To Effectively Share Code Between AWS Lambda Functions?
Use Bit to seamlessly share code across your Lambda Functions
If you’re deep into backend Serverless development with AWS, chances are you’re using AWS Lambda a lot.
AWS Lambda allows you to execute a piece of code triggered by an event such as an HTTP request, uploading an image to an S3 bucket, Adding an item to a queue, etc.
However, when it comes to Lambda function, It’s all about application logic. We adhere to software development principles like Single Responsibility Principle (SRP) and Don’t Repeat Yourself (DRY) when writing code as savvy developers.
Applying SRP in the Lambda environment means that each function is fine-tuned to perform one task exceptionally well. We also adhere to DRY principles by reusing common logic across lambda functions, avoiding redundant code in the codebase.
If you apply these principles, your Lambda functions become easier to maintain, Lambda bundle size gets smaller, Lambda cold starts get less frequent, and team efficiency increases as everyone can use standardized reusable code.
In this article, let’s discuss a novel way of sharing code between the frontend and the serverless backend in a loosely coupled manner with Bit components.
What’s the Usual Strategy for Code Reuse in Lambda?
So, what are the common strategies to share a piece of code among lambda functions?
1. The Common Directory Approach
Put your shared code in one place and have your Lambda functions reference it. This is straightforward, and tools like Serverless Framework and AWS CDK make it easier to reference files. In addition to that, We can use Serverless webpack plugin with the Serverless Framework to build an optimized lambda deployment package.
2. Native Lambda Layers
Next, we can use native Lambda Layers to share code among lambda functions. AWS Lambda Layers are pretty neat for sharing code chunks across your Lambda functions without a fuss.
However, when we want to update the code in a Lambda layer, we have to deploy the Lambda layer and deploy all the functions that depend on it. So we usually don’t include frequently changing code in lambda layers.
3. Private NPM Libraries
When you’ve got code that will be used across different projects, setting up private npm libraries is a solid move. Whenever you want to update the code, you can easily publish a new version and define the required version in the package.json file before deployment.
When Frontend Meets Backend 🤩
What if you had to share common logic between your Frontend application(E.g. React.js) and AWS Serverless Lambda function?
A Monorepo could be your answer, but be careful. If you change one thing, it might affect everything else that’s linked to it. In Monorepo, code is tied to the projects within the MonoRepo. It doesn’t provide the flexibility of sharing it with other projects outside the MonoRepo.
Is there a better solution where you can share a piece of code across your company projects or even outside the company in a loosely coupled manner?
Enter Bit.dev
Bit.dev is a game-changer. It gives you Bit Components — think of them as super-flexible packages that are easy to use and maintain. Whether it’s for apps, libraries, or UI components, Bit Components are perfect for sharing code among projects.
Learn how to install and set up Bit here.
Bit Components: What’s the Big Deal?
Bit component is an innovation from Bit.dev. Here are some core features of a bit component.
- They’re Flexible: Share your code with any project, any team.
- They’re Independent: Update one component without messing up others.
- Easy to Find: A central spot(Bit cloud) for all your components makes life easier.
- Community Friendly: Share your components, use others — it’s all about teamwork.
- Test with Confidence: Build and test your components on their own to make sure they’re solid.
Bit considers a Bit component as a first-class citizen in the Bit world. A component can be as small as a simple UI button or a simple JavaScript module. We can also create larger components with the composition of many components. It can be as large as an entire frontend app or a JavaScript library.
The beauty of Bit is that it always keeps the components loosely coupled from where it’s being used. Therefore, you can update the components, run tests, and publish new versions independently.
In addition to that, when you release a new version of a component, it detects all other components that depend on that component and runs tests to ensure they don’t break.
How to Share Code with Bit?
Let’s understand how to use Bit with an Example.
Imagine I have the following JavaScript module (format-date.js) that formats a given date.
import { format } from 'date-fns';
export const formatDate = (date, formatStr = 'PP') => {
return format(new Date(date), formatStr);
};I want to use the same module between my React frontend and AWS Lambda backend written in Node.js as shown below.
Let’s break it down into steps.
Step 01: Creating the FormatDate Component
The first step would be to export the format-date component into Bit cloud, So I can share it with my teams privately or even publicly.
Bit Cloud is a component repository. Think of bit cloud as GitHub where you push your components instead of raw code and share them with others.
In this case, I published it as a Node component in Bit.cloud.
I have also included tests to test the code such that any future changes I make will be evaluated against the test cases.
Step 02
Now that I have a reusable component, I can use it anywhere. The following image shows an example of an AWS Lambda app using the format-date javascript component.
As you can see, I use the import statement to import the module in the handler code of AWS Lambda.
Wait! How is it different from importing an npm module? 🤔
That is a good question.
The AWS Lambda app is also inheriting the Bit environment. Therefore, if you update the format-date.js and push it to Bit cloud, Bit will automatically run tests of the Lambda app to check if the lambda can break due to the new change.
Bit offers a CI server that automatically builds components and propoagates changes across the component tree. For example, look at this Ripple Build example:
As the name implies, “Ripple”; the changes are propagated across the component tree causing a Ripple in which it updates all of its usages.
This is not just applicable to one lambda function. Had we imported the date component in hundreds of lambda functions, Bit would have run tests in all Lambda to verify we don’t introduce breaking changes.
Step 03: Can I use the same module in my frontend React app as well?
Yes, you can! The following image shows a React component that uses the same backend util format-date.
I have created a React component and imported the format-date module. It’s as straightforward as importing a regular npm library.
When I change the format-date component and push it to Bit.cloud, it will verify that all the dependent applications, such as my AWS Lambda apps and React.js app, do not break due to the new change.
Conclusion
In this article, we discussed various ways to share code among Lambda functions to adhere to best practices in software development and increase performance in AWS Lambda. We have also discussed a novel way of sharing code between your frontend and serverless backend with Bit.
Suppose you work in a company where multiple teams share and reuse code. In that case, Bit will provide an excellent framework and a tool kit that helps you independently manage the reusable code while monitoring the dependencies of other applications.
If you wish to explore the demo that we explored in this article, feel free to check out my scope on Bit Cloud.
Thank you for reading.
