Are they "just components"?
A while ago, one of my colleagues sent me a link to bit.dev saying: "hey! check out this awesome collection of microfrontends and how easy it is to reuse them on your application!".
I had a look and thought, this looks awesome! but... are they "microfrontends" or just "components"? 🤔.
This is a common question and some people argue that microfrontends are just a good "component model".
So is there a difference between "microfrontends" and just "components"? Let's find out!
Solving a specific problem
A while ago there was a thread on twitter discussing microfrontends and I came across the reply below:
The microfrontend architecture is a paradigm that is trying to solve a specific problem: help large organizations to scale applications that are developed by multiple teams across multiple business units or domains. To solve this problem, applications can be split into small, reusable, independently developed and deployed frontend experiences.
So the problem is more to do with the way organizations arrange their teams and solve the issues faced with scaling and microfrontends provide the architecture and tools to allow the vertical slice of features so it is possible to achieve this separation.
Independent Deployments
You can do a lot with a good declarative component model. You can avoid accidental coupling, achieve a high percentage of reuse and even create different packages owned by different teams, however, as applications grow more and more complex, the component model might reach its capacity, and it starts getting harder to manage large codebases and coordination between different teams across different parts of the organization becomes unmanageable. One of the main features of microfrontends is that they can be deployed independently.
Independent delivery could be a real turning point for large organizations to allow their teams to deliver faster and freely and to collaborate and reuse more effectively.
Data and Business Logic
Components are small units that produce a visual representation to the user, whereas microfrontends could be described as a collection of components that provide specific value to the user and are owned by a specific team with a clear goal.
Microfrontends request all the data they need from backend services and present it to the user in a concise way. It is easy for them to follow the simple responsibility principle and because they are close to the data, it is easier for teams to own a feature end to end due to the familiarity with the business logic.
A Real Life Example
Let's take a look at a flight booking system:
Even though it is a small piece of UI, it contains a lot of functionality. It handles form validation, API calls to the aggregation systems, and the displaying and filtering of results, etc.
Every individual piece highlighted could be an individual component. The key feature here is that all these components together are providing specific value to the user and could be encapsulated under a single domain.
Now let's say that there is a dedicated team in charge of this frontend experience and that is their responsibility to maintain and release new updates as required.
If we were to follow the monolithic approach our team would need to have the context of the entire application, its build system and project structure, additionally, coordination with other teams must exist in order to release new updates that fit into the release cadence.
A first approach to solve coordination issues would be to wrap the entire booking system into a larger component and then share it as a dependency so it can be consumed by different parts of the application, however, this will still require the main application to be deployed in order to include the new updates and other teams must be informed that a new update has been published so they can add it to the main application.
Microfrontends reduce the need for coordination by providing individual teams with a separate codebase and a build system for the part of the application they are responsible for. There is none to little communication required since the new updates will be deployed by the team who owns the feature and the integration to the main application can be achieved by client or server-side composition at runtime and in some setups avoiding entire server deployments or restarts.
Conclusion
Microfrontends are more than just "components". They are a new way of designing your application to allow teams to deliver features independently. Teams are responsible for features end to end and work towards specific goals.
This new paradigm aims to help with this new design by providing the technical tools required to group components together and assemble them on the page under a cohesive experience providing faster development and delivery of new features to the users.
Top comments (2)
Iiiinteresting, do you have an example of how to package a microfrontend neatly? With components in vue.js for example I tend to try to make sure everything necessary is within the single vue.js component file. With a microfrontend having DB access as well, in the way my sites are currently set up at least, it would mean multiple files. For ex, in a vuex/vuejs microfrontend would you package both a component and a vuex store together and then store them in one spot on the target project under the specific feature's name??
It is very important to avoid accidental coupling and try to follow the single responsibility principle + the business domain that your microfrontend is serving. You should be able to deploy everything in your package independently without the need for anything else to be deployed for the functionality to work. Apart from that you can follow any project structure that your build system or framework requires. 👍