Can We Reuse Code Between Microservices?
Simple technique to share code across Microservices
If you are new to Microservices, this is a fundamental question most of us must answer at the project’s inception. But, it also causes lots of confusion since Microservices should be self-contained, and reusing or sharing code across Microservices can cause fundamental challenges to the concept.
Some of you might wonder why sharing code in a traditional way is a problem for Microservices. It will again end up in dependency chaos, making the set of Microservices a Monolith in the long run.
Therefore it is essential to keep the self-contained nature of Microservices, where each service can be independently developed by a team and deployed without affecting the others while using different versions of shared code.
This article will take you through a few approaches to building robust and self-contained Microservices without code duplication. First of all, it’s essential not to duplicate code between Microservices, especially if it’s the same code being copied and pasted. It can cause more harm than having dependencies.
TL:DR: Watch this to learn how to …
- Compose 2 component-driven microservices from scratch.
- Easily add, modify, and remove components from your services.
- Share managed components between services to radically speed up backend development.
- Easily manage dependencies and updates between components and services.
- Gradually build a reusable toolbox of backend components.
- Modify and update components in the context of another service or project.
- Avoid configs and have a smooth dev experience.
Sharing Code
The approach I would recommend is to build your code as reusable components that fundamentally facilitate reusing code. Bit components do just that. Otherwise, you must depend on an external repository or registry to maintain the shared code (e.g., Utils) and use a specific version within a Microservice.
Either way, you can keep the Microservices self-contained by having their lifecycle, and even if the shared code is changed to a new version, the services which need to use the more recent version can use it without impacting others.
Reusable Code Units as Components
It is also essential to understand how we structure each reusable code component. I often use Bit Components with its lifecycle and semantic versioning and stored in scopes in Bit Cloud. Each component will be built and tested independently from others to construct robust components (Units of Code) to share between Microservices. Other than that, let’s also look at several traditional approaches to sharing code.
Using a Package Manager
One of the tools you can use is a package manager. For example, if you are developing NodeJS applications, you can use NPM Package Manager. It will require a Private Repository for commercial projects, and I often recommend creating NPM Orgs that support namespaces for components. You will need a paid version, but it’s worth it.
Using Source Control
When you create shareable components and store them in a Git Repository, you can use the Git Tags to version each release and use it within your Microservices if you use NPM. You can define it in the package.json, referring to the commit hash with the URL.
{
"name": "microservice-a",
"version": "1.0.0",
"dependencies": {
"serverless-dynamodb- local":"git+https://github.com/99xt/serverless-dynamodb- local#67ef2998624e10f5ef734fbcc6b70b471b057ed0"
}
}For more details, refer to the GitHub URLs as dependencies section in NPM documentation.
You can also use Git-related technologies such as Git Submodules and Git Subtrees .
Overall, you can use these approaches to reuse code across Microservices. However, each option has challenges you need to know before using them at scale. Therefore, the best practice is to try them out and see how it fits your product (tools and technologies) and your team before using them at scale.
