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 micro-frontends and how easy it is to reuse them on your application!”.

I had a look and thought, this looks awesome! but… are they “micro-frontends” or just “components“? 🤔.

This is a common question and some people argue that micro-frontends are just a good “component model“.

So is there a difference between “micro-frontends” and just “components”? Let’s find out!

Solving a specific problem

A while ago there was a thread on twitter discussing micro-frontends and I came across the reply below:

We generally solve that problem with… components

— Dan Abramov (@dan_abramov) May 26, 2019

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 micro-frontends 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 micro-frontends 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 micro-frontends 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.

Micro-frontends 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.

Micro-frontends 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

Micro-frontends 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.