We have discussed the use of micro-frontends across several of our blog posts; why do we talk about them so much and can they really be a part of the solution to application modernization? gravity9 Solutions Architect, Tomasz Maruszak explains.

WHAT IS A MICRO-FRONTEND?

The micro-frontend extends the concept of microservices on the backend to the frontend layer, breaking down the frontend monolith into smaller, defined, and independent frontend services (web applications) that can be written in multiple frameworks and are easy to manage. Using this architectural approach enables efficiencies and scalable frontend development, particularly across multiple teams.

A micro-frontend approach combined with a microservice architecture delivers end-to-end functionality while allowing for a vertical breakdown of individual systems. Each such vertical can then represent a specific bounded domain context (or business problem).

WHY WOULD YOU BUILD A MICRO-FRONTEND?

Smaller scope to manage:

The simple answer is that as with microservices, smaller frontends are more manageable. Individual developers gain autonomy, enabling them to focus on the specific problem they are solving. Their frontend application can be developed, tested, built, updated and deployed independently as required.

Independent and focused teams:

Different organisations have varying levels of expertise which can be delineated by technology specialisation (frontend vs. backend vs. full stack), or by business knowledge. With micro-frontends it is much easier to allocate expertise to specific, bounded frontends, enabling developers to work independently, providing the contracts between components are well defined. Likewise, developers can be assigned to the business context they know best.

Independent releases:

The efficiency of independent and often smaller changes is also increased. For new feature releases in specific micro-frontends, or for bug fixes pertaining to a small subset of your micro-frontends, you can release and deploy changes for just this subset. All that’s needed upon deployment is a refresh of the single-page application (SPA) page and the browser will pull the latest scripts and assets for your micro-frontends to run the latest version. A ‘hot reload’ during runtime that refreshes only the updated micro-frontends themselves can also be achieved.

Coping with Mixed technology frameworks:

We all know that frontend technologies change at pace. Starting back with DHTML, jQuery, Knockout, through to SPA frameworks (Angular, React, Vue) becoming the standard, and looking forward to web assembly (Blazor), change is a constant in the frontend space. There is quite a paradigm shift even between Angular 1 and Angular 2+ and this acceleration of technology will only pick up pace.

If you adhere to standards when creating micro-frontends, each will benefit from an isolation that enables you to write them within different frameworks, or different versions of the same framework, and still have all your micro-frontends appear and operate seamlessly in one browser DOM. This flexibility becomes invaluable when hiring the next generation of frontend developers that will only want to develop in the latest, greatest SPA framework.

Easier upgrade paths:

Imagine that 10 years ago you invested in a new mission-critical frontend for your core business that you built using traditional frontend development techniques on Angular 1.0. These days it’s difficult to find talent willing to add new features in legacy technology, not to mention frameworks such as Angular 1.0 that are out of their support lifecycle. The effort required to upgrade your entire monolithic frontend to a modern framework might not seem worthwhile to add minor features, but you also struggle to find developers willing to implement these minor features that you need for your business to keep pace. What could you have done differently?

What if, 10 years ago you instead made the decision to build your application using a micro-frontend approach? Your application is now made up of small and isolated components, so the extra investment to rewrite or upgrade each one while adding new business features becomes much more palatable. You are able to invest specifically in the parts of your application that are driving value for your business, allowing you to benefit from technology improvements and more productive development paradigms as you do so. You’re also able to remain an attractive prospective employer to a new generation of developers who want to be using leading-edge technology frameworks.

Easy path to extend legacy system with new framework:

The reality is that many businesses have large monolithic web applications that “just work” and for which little thought is given about frontend modernisation. Actually, in most cases it is possible to extend such monolithic frontends to integrate with a newer micro-frontend approach. A hybrid architecture can be established for the application, where any new functionality or planned modules can be isolated into their own micro-frontends and any new development activity can be built gradually using micro-frontends. Additionally, changes to existing functionality can optionally be taken as opportunity to incrementally modernize components of the monolithic frontend into the new micro-frontend approach, enabling a gradual path to overall modernization of the legacy frontend component.

SOUNDS GOOD, BUT WHAT ARE THE CAVEATS?

Mind shift and learning curve:

As with anything new there is always a learning curve for the team which takes time to overcome. Additionally, there are technical considerations such as configuring cross-origin resource sharing (CORS) once all your micro-frontends are housed together under a domain, and how authentication tokens are exchanged. The good news is that once your team have completed this process once, then your organisation will possess the key to productivity.

Framework and library conflicts:

At some point your many micro-frontends will be executed in one browser window (DOM). Each micro-frontend can be written using different libraries or different versions of the same library. This advantage comes with a potential for issues at runtime that need to be accounted for during testing. While there is always the ‘chance’ something will not work or be compatible, mainstream frontend libraries have for some time been using modules that allow for isolation.

Browser compatibility:

Depending how the micro-frontends are implemented they could rely on web standards that are not implemented on older browsers such as Web Components, however, often for older browsers there are polyfills available to increase coverage.

Performance:

A consequence of having many smaller micro-frontend applications in comparison to a single large monolith frontend is that there are likely to be many more files (JavaScript, CSS, assets) that need to be loaded by the browser to display the page. This potentially increases latency and page load time but will depend on the page bundling approach you take; to minimize page load performance cost you may choose to pre-bundle on the fly all the individual micro-frontend scripts and serve them in one go into the housing frontend, which will achieve a similar page load performance to traditional approaches.

Additionally, there will be more SPA frameworks that need to be initialized when all the micro-frontends start in one browser DOM. While this is generally considered to be relatively fast it does delay the first page load time.

So what? 

While there some potential downfalls to micro-frontends, our view is that these are rapidly overcome and overshadowed by the benefits. Micro-frontends create more manageable, efficient, and future-proof applications that enable scalability at both a micro and macro level. As organisational requirements develop, new technologies evolve, and customer demands change the micro-frontend application architecture has the ability to scale, evolve and version as required. Much like gravity9, micro-frontends are just getting started!