At Invillia, every Wednesday at noon, we stop for an hour to nourish ourselves with the tips, how-tos, good practices and trends selected by our specialists in Product, Agile, Back and Front, Mobile, Quality, Security and Data. A vital exchange of experiences for those who love the new. And essential for innovation to never stop. If technology is in the blood. We make sure to keep it circulating more and more_
IN THE VEIN_ Extending the idea of microservices to frontend development_
5-minute read
We leave here the main learnings of the edition presented by Luís Oliveira, an expert in frontend development at Invillia in the React ecosystem, about the added value of breaking a monolithic application into smaller pieces, more focused on each domain area.
The concept
The term micro frontends first appeared in ThoughtWorks Technology Radar. Extending microservices concepts to the frontend world. The idea behind micro frontends is to think of an application as a composite of features owned by independent teams. Each team has a distinct business or mission area that cares about and specializes in. A team is cross-functional and develops its capabilities end-to-end, from the database to the user interface.
Monolithic Frontends:
A little of history
When web development started, it was much more difficult and complex. There was no back or front, it was a fully coupled, fully monolithic application. Making it difficult and costly to maintain when scaling. And as time went by, there was a great revolution called AngularJS, which already brought a decoupling of the front from the back, but even so, there was an exponential growth of the backend, as the application grew there came a time when it became a huge monster. And that gave rise to microservices, which is separating the back into small pieces in a fully scalable way. But the frontend was still monolithic.
Why did the idea for the microfrontend come about? Why is it necessary to break the frontend into small pieces of code like in the backend? For the same reason of the backend. It starts to get gigantic.
Micro frontends then emerged as an architectural style in which frontend applications are delivered independently and compose a greater whole. Micro frontends are not a lib or framework. They are a methodology for distributing large applications into smaller portions.
The result? Building modern apps with multiple teams that can deliver functionality independently.
But the micro frontend can be confused with teams in verticals. Each one works with their front, back and database, but they are still large and centralized. The responsibility is still not as small as the micro frontend itself.
The real micro frontends
Now we’re starting to get an idea of what a micro frontend actually is.
What is a monolith frontend? It’s an entire application built on a single technology, in this case, React.
What is a micro frontend? That’s when we have lots of little pieces of the application that are technology agnostic.
You can create micro frontends in the following ways:
- iFrames – you make several different iFrames and merge them all into several HTML containers
- NGINX – here there are several servers and they are all rendered separately, managing to have your pages on different servers
- Web components – similar to iFrames, you have several micro frontends and several HTML divs that are rendered in your container
- Monorepos – here you have several small applications and instantiate them within a structure
- Module Federation – the best option for micro frontends
What are the main motivations for using microfrontends?
- I want to abandon my legacy – separate the old code and study what makes sense to leave or not
- Agnostic technologies – testing new technologies and not having to worry about migrating the entire code
- Working in multiple teams – being able to work with different teams without breaking your code
- Separate application into parts – for better management, scalability and flexibility
- Applications or libraries sharing
Now let’s go a little deeper into Module Federation, which is a feature of Webpack.
Webpack and its Module Federation
Webpack is a bundler of all the tasks that are performed in the frontend. It’s what makes the minification of all the application’s files, optimizes images, validates the compatibility between browsers. All these tasks are done based on the settings the developer makes.
Webpack takes all files and makes them compatible for all browsers to understand:
So let’s go to the icing on the cake that is the Module Federation, a feature present in Webpack4 in beta and in production in Webpack5. It allows developers to share dependencies between applications, and define which modules from other applications will be consumed and which modules will be exposed.
What Module Federation solves:
- Duplication of libraries
- Bundle size
- Performance
- Code splitting
After all these concepts, we still have remote components, which are special components that can load other components not in the same codebase on the web.
More info and sources:
- https://github.com/module-federation/module-federation-examples
- https://micro-frontends.org/
- https://github.com/lfoliveir4/react-microfrontends-boilerplate
At Invillia we have the know-how and experience in the most state-of-the art technologies and methodologies on the market, applying the best to each case. We are always studying, improving knowledge, anticipating what’s next, testing, going further. To create and continuously evolve together with those who are transforming their markets, the most innovative, resilient, robust, scalable digital products and services with the best user experience. Engaged by data, people and action_