
-
What is Mirco Front-Ends?
- Micro front-end is just code for a portion/component of the web page.
And web page hosting that component is called host page.
- Micro front-end is just code for a portion/component of the web page.
- We also have a micro front-end framework that sits between micro frontends and host page, that manages loading and unloading of micro front-ends.
-
Advantages of Micro Front-ends
- Team Scalability :
- Here more people will be able to work on a given webpage.
- Because MFEs are versioned independently deployed. So, each one of those is its own project and
then theMFE would go off onto s3(Simple Storage Service) and then be loaded by the page. So that the MFE team can work independently of the host page team and that can be deployed even if the hostpage isn’t deploying. It makes an MFE different from a library.
- Strategic vs Tactical Focus
-
It allows the host page team to be more of a platform team focused on
-
long-range deliverables,
-
contracts,
-
how to manage the performance to the site,
-
how analytics can be routed, that kind of stuff.
-
-
MFE teams are based on tactical delivery that’s more customer-centric. It engages the customer better.
-
So, teams can work 100% on their particular area, your host page team is gonna be able to 100% concentrate on making a great host page and your MFE tactical teams are going to be 100% engaged around what’s going to make a better conversion what’s going to get more customer engagement. Helps to separate infrastructure and customer-centric work differently.
-
- Reuse: Components can be reused, long as those host pages conform to that as long as it maintains the MFE standards and those contracts.
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Organized around business capabilities
- Owned by a small team
- Team Scalability :
-
Disadvantages of Micro Front-ends
- Complex:
- It’s just a more complex system. In a traditional model, you have a project and it gets built into a docker’s container probably and then gets end to end tested to make sure that it passes, everything and then gets deployed. And you know, sites work as long as the servers are up it’s all good.
- In this model, though you’re gonna have a host page and it’s going to be dynamically loading stuff from other teams and those teams may mess up and may take down the page, javascript is a single-threaded execution model, it’s not particularly sandboxed, it’s not really sandboxed at all.
- so it’s very likely that you’re gonna get runtime issues that you didn’t expect.
- No standards:
- There’s no standard, there’s no winner, there’s no current like redux in the MFE space.
- and honestly, I don’t think there’s probably ever going to be. Because site to site there’s going be such variability, and their requirements that I don’t think that’s realistic.
- Complex:
-
Core concepts behind Micro Frontends:
- Be Technology Independent
- Isolate Team Code
- Create Team Prefixes: Use naming conventions where isolation is not possible yet. Namespace CSS, Local Storage, Events, and Cookies to avoid collisions and clarify ownership.
- Favor Native Browser: Features over Custom APIs Instead of building a global PubSub system, use browser events for communication. If there is a need to build a cross-team API, try to keep it as simple as possible.
- Build a Resilient Web design: The features should be useful, even if JavaScript is unable to execute. To improve perceived performance, use universal rendering and progressive enhancement.
-
Conclusion:
-
It heavily depends on your business case, whether you should or should not use micro frontends. If you have a small project and team, micro frontend architecture is not as required. At the same time, large projects with distributed teams and a large number of requests benefit a lot from building micro frontend applications. That is why today, micro frontend architecture is widely used by many large companies, and that is why you should opt for it too.
-
References :
Comments are closed.