This content originally appeared on Bits and Pieces - Medium and was authored by Chameera Dulanga
They differ fundamentally when it comes to code sharing. Get to know why
Over the years, frontend architectures have been significantly influenced by Microservices. Developers choose Microservices since it allows them to distribute the development and release the changes frequently.
With the influence of Microservices, developers adopted concepts like code sharing to Microfronteds. However, we can’t completely map those concepts between Microservices and Microforontends since they are fundamentally different. For instance, Microservices are distributed systems, and Microfrontends at runtime are running in the users’ browser. Therefore, it significantly influences how we reuse code.
So, this article will discuss how we should use code sharing and key differences in code sharing between Microfronteds and Microservices.
Code Sharing in Microservices
Code sharing in Microservices can be a questionable topic for many as the main concept of Microservices is to build self-contained services. However, since they are distributed systems, we must treat them independently and minimize code sharing. If not, there can be dependency issues, and your project can become a Monolith in the long run.
Nevertheless, there can be unavoidable situations where we need to use code sharing between Microservices. In such cases, it is essential to stick with the best practices to avoid getting caught in a dependency trap.
Sharing as Libraries
In this approach, you can extract the sharable code from the Microservices and publish it as a library in a package repository like NPM or Nuget. Then, each team can install that library or package into their services and use it without interference from other teams.
Although this sounds simple, there are several things you need to consider before using this approach.
All the Microservices that wish to use the library should use the same language as the library. Then, you need to assign a separate team to take ownership of the library since there can be conflicts if multiple teams start to make changes.
Choosing the shareable code is the most important thing in creating libraries. You must select the minimum code required for the functionality, and it should not require regular changes.
Sharing as Microservices
If you have a large code that keeps changing rapidly, sharing it using a library or a component will be inefficient. In that case, the best way to share it is to create a new Microservice and expose the code through an API.
Unlike the other 2 approaches, this approach has no language limitations since we expose an API. However, creating and painting a separate Microservice will increase the workload on developers.
Microservices written in any language can access the code. However, if you use this approach, it is advisable to follow design patterns like Saga or Sidecar to ensure data persistence in complex transactions. In addition, you need to allocate a separate team to maintain the new Microservice.
Although I have mentioned the above methods as code-sharing techniques in Microservices, I highly encourage you to avoid code sharing between microservices as much as possible. By nature, Microservices are distributed systems, and sharing code between them can overshadow the advantages of using Microservices.
Code Sharing in Microfrontends
Compared to Microservices, code sharing can be easily adapted to Microfrontends. When an application is executed, all the frontend components run as a single application in the user’s browser. Regardless of how you develop, all the Microfrontends get combined at the runtime. So, sharing code during the development process does not violate the fundamentals of Microfrontends.
In addition, users directly interact with frontend components, and you need to ensure that each component has the same design and feel. So, the most effective way is to share code between Microfrontends rather than repeating the same code in every component.
I think now you know why code sharing is more suitable for Microfronteds. So, let’s discuss the different techniques we can use for code sharing between Microforntends.
Sharing as Libraries
Like Microservices, you can extract the code that needs to be shared and publish it as a library. For example, if you have a utility code for date formatting, you can publish it as a library and use it in all the components.
I won’t go into much detail about this approach since I have discussed all the challenges of this approach under the Microservices section. However, this approach is not suitable if your code needs regular updates.
Monorepos and Polyrepos
Both monorepos and polyrepos are widely used to manage Microfrontend codebases. When it comes to code sharing, we can benefit from both of their characteristics.
Monorepos
In a monorepo, all the Microforntends are managed in a single repository. Each component will have a separate folder in the repository, and all the teams will have access to the repository. Similarly, you can create a shared folder and place all the shareable code inside it.
If you use this approach, you need to ensure that code included in the shared folder should not change frequently. Also, access management to the shared code can be difficult since each time has access to the repository.
Polyrepos
In polyrepos, each project or component has an individual repository. It allows you to manage user access to components and manage individual codebases. However, code sharing in polyrepos can be a bit more difficult than in monorepos.
In polypores, you can use Git Subtrees or Git Submodules for code sharing. These two methods allow you to keep a copy or a reference from another repository. So, you can use a separate repository to maintain shared code and fetch them into your repository using these 2 methods.
However, fetching from Submodules and Subtrees can be difficult when you have many shared components. For example, you will have to bring and push changes from and to shared repositories continuously, and there will be many conflicts to handle.
Sharing as Components
Sharing code as components is one of the latest techniques introduced for code sharing. You can use a platform like Bit to implement this approach easily, and it will solve most of the issues discussed in previous approaches.
For example, code sharing through libraries can get difficult due to life cycle issues or continuous code changes. If you use component-based code sharing, you will still get the same feeling as a library, but you do not need to worry about life cycle issues or continuous updates.
In addition, the component-based code sharing approach brings the best of monorepos and polyrepos into a single place. It tracks all the components individually while allowing developers to make changes and share them across teams easily. Also, there is no limitation to the maximum number of components you can share.
However, this approach may be new to many developers. So, I encourage you to experiment with Bit and adopt this approach to build your Microfrontends since it resolves some of the significant issues in Microfntend code sharing.
Key Takeaways
This article discussed different code-sharing techniques for Microfrontends and Microservices. In addition, I highlighted why developers should avoid code sharing in Microservices and why developers should use code sharing in Microfrontends.
In a nutshell, Microservices are distributed systems designed to act independently. If we share too much between Microservices, it will break the fundamental basis of Microservices. In addition, code sharing can increase the number of dependencies between services and make it difficult for the developers to work. So, we should avoid using code sharing in Microservices as much as possible.
When it comes to code sharing, Microfrontends acts completely different from Microservices. Although we develop Microfontends individually, they all get bundled together in the browser at runtime. So, we do not violate any fundamentals of Microfrontends by sharing code. Apart from that, it is necessary to have the same style and user experience in all the frontend components. Therefore, the best way to manage an identical look and feel in a large project is to encourage code sharing.
To conclude, there are many reasons why we should and should not use code sharing in Microservices and Microfrontends. I hope this article will help you clarify doubts and understand the correct techniques to share codes in Microservices and Microfrontends. Thank you for reading.
Go composable: Build apps faster like Lego
Bit is an open-source tool for building apps in a modular and collaborative way. Go composable to ship faster, more consistently, and easily scale.
Build apps, pages, user-experiences and UIs as standalone components. Use them to compose new apps and experiences faster. Bring any framework and tool into your workflow. Share, reuse, and collaborate to build together.
Help your team with:
Learn more
- How We Build Micro Frontends
- How we Build a Component Design System
- The Bit Blog
- 5 Ways to Build a React Monorepo
- How to Create a Composable React App with Bit
Differences in Code Sharing Between Microservices & Microfrontends was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Chameera Dulanga
Chameera Dulanga | Sciencx (2022-09-15T08:00:42+00:00) Differences in Code Sharing Between Microservices & Microfrontends. Retrieved from https://www.scien.cx/2022/09/15/differences-in-code-sharing-between-microservices-microfrontends/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.