Code sharing with Bit

Working with microservices brings to the table a big range of advantages (scalability, bugs isolation, etc). However it also presents a number of new problems to tackle.

One of the problems we had to address recently was related to the use of the same code (a component which handled an app feature) in different microservices. To work it out we considered a few alternatives:

Copy & paste...

Of course, it works but not really an option. The easiest (at the beginning) and the worst for obvious reasons (DRY please!) Any change in our component would involve the same copy & paste process in the rest of microservices... and the risks everyone should avoid: forgetting what/how to do it, manual and human mistakes...

New service

Extract the component logic to an own separate instance and work as a restful service. If a microservice needs to use one of the component functionalities, it will make a request to the new service. The architecture of the solution would look something like:

Pros:

• The code is just contained in one place (no repetition).
• Easier deployment. Changes would need to be deployed to just one instance.
• Component isolation. This solution would follow a strict distributed architecture with its advantages and downsides.

Cons:

• Ideally, the new service would be located in a separated AWS instance (or server) what would increase the infrastructure costs.
• The performance would be affected. The response time to get the result of the requested operation would be increased as we need to add up the latency to the computation time.

In general, this looked like a good solution but we wanted to save the time and money of setting up a new instance for deploying a small component.

Bit

Carrying on the search of further tools we found what would be our choice: Bit. Bit is a component manager that helps you to spread your code across different projects avoiding the problems listed above.

Though it is self-proclaimed language agnostic, I’ve found it mainly oriented to JavaScript apps, what was just ideal for our purpose.

Basically, you can encapsulate any piece of code in a Bit component and store it in a central repository that you can use in complement to Git. With this new tool, I think this was especially important from a development point of view, you can make a change from any project where the component is found and keep it synchronised in the rest.

Additional advantages of Bit are:

• Your components can be installed with a standard package manager like npm or yarn.
• It will handle automatically dependencies with other packages, ensuring is correctly isolated.
• Version tracking. You can find out what is the used version of the component and if it is up to date with the latest.

Integrating it with your workflow

You can create your own workflow to use Bit. A common example of use following the problem we initially had to solve:

Microservice A

We start from an existing package component_x located in the Microservice A codebase. We need to create and export it as Bit component:

Output:

With

we can check operation was performed correctly and we created our new component.

Output:

and with

we can access to the whole component information (dependencies, language, etc)

Output:

In this case, the component uses the package sequelize and it’s been automatically detected and included as a dependency. Now, we can version it through:

Output:

and export it to our utilities Bit scope (similar to a Git repository).

Output:

And that’s it! Our component is ready to be used in other projects.

Microservice B

The team responsible for implementing the microservice B needs the component X. Using npm they can install it as standard external dependency and would work out of the box!

package.json

Easy, right?

What about if the team needs to make a change? Then, they could import the component to the project codebase:

Output:

Double checking the component folder has been included:

Output:

and the external dependency has been replaced with an internal reference:

package.json

Now, the code can be modified and the component re-versioned and exported it back to allow other projects (Microservice A) to use the up to date version.

Note: remember to use the --eject flag when exporting the component to move it as an external dependency again and keep the code of your main project clean. If you forget it you won’t be able to do it later though, hopefully, this limitation will be solved soon.

Is Bit appropriate for me?

Bit, with a correct workflow, can be used to share any bundle with your team and help you to avoid most of the problems when reusing code. My colleagues have already created a bunch of React components in Bit to be used in different projects.

However, as we’ve seen other solutions could fit better or complement Bit depending on the nature of your projects and team.

The best way to check it is working with it yourself, especially now, v13 has been released.