MicroFrontends and Services Companies
TLDR; Microfrontends can help solve many problems around building large web apps with maintainable, good quality code. With micro fronetends, each team of devs works on building a dedicated suite of microweb apps. For example, the checkout team building a single button for the checkout cart, another small component with a cart icon and checked out items cart, and so on. And similar to microservices, microfrontends also ensure that each small unit can be individually altered to whatever extent needed, without altering any of the other components.
When it comes to services companies, like the one I work for, one of the major issues for them if they provide frontend design and implementation services is managing resources. Especially, if like us, you want to hire nothing less than the best.
With not enough developers experienced in a language to go around scaling for larger projects becomes an issue. Hiring good developers is a problem every company faces and with limited time to hire developers “we are not scaling fast enough!” becomes a preamble to a horrific tale of burnt-out devs.
MicroServices on the backend side make it really simple to manage backends. The devs can easily split a backend into many smaller backends each with its own dedicated work and independent of the other’s internal workings. This means one or a few devs can work on one part of the backend application without any regard of how the other team is working on their chunk of backend goodness. The only thing the teams have to agree on with each other is the way data is shared across these smaller chunks. The rest is inconsequential.
In comes micro frontends. A fairly newer approach to working on frontend applications. To put it simply once can say its the frontend equivalent of microservices. Micro Frontends focus on splitting a frontend web application into many little chunks which share data with each other but whose inner workings are completely independent of each other.
From the micro frontends perspective, one can view a single web application like lego sets based city. You get a lego set and build a house. You get another one and build a hospital, another one, and a garage and soon you have a city. Each set defined its own building or structure with its own functions. But collectively they formed a city.
Similarly, in the micro frontends case, we build one small piece of a micro frontend. Lets say we build a forms component to build dynamic forms using angular. The forms component has its own validations and input parameters as well as its own event listeners that it exposes. Let's say we want to add a VR view to our application but the best way to do it is through reactVR in our case. So we build a reactVR component that takes some inputs and exposes some event listeners. Let's say we want a swipeable cards interface, something like vue-swing and the developer available is a pro vue machine ( :P ) so we build a vue based wrapper which wraps components passed to it in a swipeable interface.
Now since we have 3 different components in 3 different frameworks how can we make them play well together?
Custom elements are the answer. Custom elements are what makes micro frontends possible. If we make all these components into HTML custom elements, we can use them in a single page without having to install added dependencies.
Using a custom element is as simple as importing it, and using the new tags in an HTML document. — webcomponents.org/introduction
Host all of the custom elements at a CDN and just use that as a source for any web app you might want to use them in. At the frontend code simply import them using script tags. The best part is since each of these is a separate app on its own, we can make changes to these components build them and push the version to the CDN and all our apps using them will automatically pick up the newer version of the component, when the script loads.
<script type="module" src="node_modules/@polymer/paper-button/paper-button.js"></script>
...
<paper-button raised class="indigo">raised</paper-button>Above we can see a simple paper-button custom element being loaded and used in a web app.
Now since we aren't constrained to a specific framework we can use whatever framework suits the client needs for whatever part of the app and just combine them all in a single application. Since we are framework agnostic now we have a vast pool of floating resources which can build custom elements for specific components and focus on that specific part of the application only. A diverse resource pool makes for wider architectural understanding and wouldn't cause resource strain for a specific framework.
This solves the problem of not having enough developers of a specific framework. The only predevelopment steps involved are actually building teams based on working on a certain separable part of the application, rather than building teams to work on a whole view or feature.
Honestly, I could go on an on about micro frontends but that's not the purpose of this article. For good developers, all you need is a nudge in the right direction and this article is an attempt towards that. If you want to learn more about micro frontends checkout the micro-frontends.org website. It really makes the concept easy to understand and simple, much better than I could ever really do.
Happy Coding!
