Understanding Micro Frontends

Introduction

Large applications have profited in several ways as a result of microservices improvements. It aids with the development, deployment, and scaling of separate components of the application backend. Nonetheless, many people noticed that the front end faces comparable issues. That's where we start breaking down the frontend monolith into micro frontends.

Modern online applications are more complicated, with multiple teams managing them at times. You may have features in your application that were created by separate teams, and you wish to deploy only a few of them into production before releasing the full application. If you just have one repository, how do you manage many teams and release schedules?

The majority of these complicated programs are client-side, making them more difficult to maintain. This monolithic large application has a few other flaws as well.

In this article, I'll go over the benefits, drawbacks, implementation, of typical micro-frontend architecture.

Tradeoff of Micro-frontends

Micro-frontend codebases can be smaller, more manageable.

By definition, micro-frontends should have smaller codebases than monolithic frontends. This detached code is easier to browse, and developers are less likely to make mistakes as a result of the complexity. Developers are typically able to go through code more quickly and with less effort, in addition to having higher correctness. This is especially true when developing process-driven apps that may already involve the development of complex processes.

Micro-frontends promote reusability across process and case management

Micro-frontends are very useful for businesses that develop a number of different apps with similar workflow requirements. Enterprises may use this design to extract common parts from case management functions, saving time and effort when building new processes. For example, if a company has many sites that require a workflow for payment processing and the other automated business processes it triggers, they may reuse the same functionality across all of their apps rather than having to develop it from the ground up each time. By using the ability to design and create a frontend component once and reuse it in a number of scenarios, this reusability may help businesses save a significant amount of time and money over time.

Micro-frontends allow you to democratize user experience User experience may be the misery of many modern development teams. In a world where software is constantly being created and deployed, a centrally controlled UX may quickly become a bottleneck. Microservices democratized backend development, but micro-frontends extend the service-oriented mindset to every stage of the development lifecycle. Enterprises may more completely adopt a robust microservice-like mindset by breaking apart a frontend monolith. This method enables cross-functional teams to produce both frontend and backend functionality independently. Instead of focusing on offering a specialized skill set, these teams are vertical, focusing on delivering a specific use case or product from start to finish. This reduces bottlenecks by breaking down departmental walls and promoting greater collaboration between backend and frontend engineers.

Constraints of Microfrontend

• Complex testing of the application as a whole. It might be more difficult to get a comprehensive view of your program now that it constantly loads stuff. Although each front end may be evaluated independently, a real-world user test is necessary to guarantee that the program works for the final user. Because it is agnostic to implement specifics, you can use standard black-box end-to-end testing using tools like Selenium or Cypress;
• The a wide variety of standards you have to keep up with. Because the app is split down into smaller sections, it might be difficult to keep all developers on the same page. To provide a high-quality user experience, it's critical to keep everyone on the same page; If your project is large and you have more than one front-end team, adopting micro frontends is a smart option for your business. It is not worth the effort with a small group Each micro frontend's deployment, assembly, and configuration procedure will be unique, necessitating additional work.

Different Approaches to Micro-Frontends

Build-time integration This type of approach publishes each micro-frontend as a package and then lets the application container build them as library dependencies. The following is an example of a package.json that is based on Cam Jackon’s micro-frontend demo:

{
  "name": "@feed-me/container",
  "version": "1.0.0",
  "description": "A food delivery web app",
  "dependencies": {
    "@feed-me/browse-restaurants": "^1.2.3",
    "@feed-me/order-food": "^4.5.6",
    "@feed-me/user-profile": "^7.8.9"
  }
}

Run-time integration via Web Components

Web Components are a collection of technologies that enable you to design reusable custom elements. Custom elements, shadow DOM, and HTML templates are the three primary technologies. It's a sort of "Runtime integration via JavaScript" that's unique. The only distinction is that you choose to work with Web Components. Cam Jackson gives an example of a micro-frontend built with Web Components:

<html>
  <head>
    <title>Feed me!</title>
  </head>
  <body>
    <h1>Welcome to Feed me!</h1>

    <!-- These scripts don't render anything immediately -->
    <!-- Instead they each define a custom element type -->
    <script src="https://browse.example.com/bundle.js"></script>
    <script src="https://order.example.com/bundle.js"></script>
    <script src="https://profile.example.com/bundle.js"></script>

    <div id="micro-frontend-root"></div>

    <script type="text/javascript">
      // These element types are defined by the above scripts
      const webComponentsByRoute = {
        '/': 'micro-frontend-browse-restaurants',
        '/order-food': 'micro-frontend-order-food',
        '/user-profile': 'micro-frontend-user-profile',
      };
      const webComponentType = webComponentsByRoute[window.location.pathname];

      // Having determined the right web component custom element type,
      // we now create an instance of it and attach it to the document
      const root = document.getElementById('micro-frontend-root');
      const webComponent = document.createElement(webComponentType);
      root.appendChild(webComponent);
    </script>
  </body>
</html>

From these choices, which type of micro-frontend approach will you choose?

Highlights before choosing a Micro Frontend Framework

For good reason, the notion of Micro Frontend is all the rage in the development industry right now. It's a fantastic answer to a variety of front-end development issues. It's only logical that you'd want to include it in your development procedures. However, if not done correctly, it can be time-consuming, resulting in more hurdles than answers. So, before you begin shortlisting frameworks for your Micro Frontends, consider the following five factors:

• Team Size
  If you have a single small team managing web application development, several of the primary features of Micro Frontends, such as separate team operations, may become obsolete. Micro Frontend architecture generates overheads that make it difficult for a single team to handle several components efficiently. The goal of delivering Micro Frontends is undermined when one developer moves between coding and deployment processes for several component slices.
• Communication Between Components
  All of a component's code must be contained within a Custom Element in Micro Frontend. The design makes use of the Document Object Model (DOM) to transport information between distinct components, and element attributes are critical for allowing communication between them. Object references might be lost in transition if this declarative method is not used. This is an important factor to consider while deciding which Micro Frontend frameworks to choose.
• Component Division Strategy
  Micro Frontends isolate component codes, allowing teams to update, grow, or convert components without making a major upfront investment. It's crucial to remember that there are several methods to slice your web components for this. One strategy may be to divide the team into two groups: one for each child component and another for shared components. Alternatively, you might achieve this by not adhering to a strict Micro Frontend strategy — that is, deciding which aspects require slicing into components and which can go without. You can still deconstruct a monolithic frontend without slicing it too thin.
• Usability
  Remember to think about usability while picking a framework for your Micro Frontend architecture. Every framework has advantages and disadvantages. As a result, a framework that works flawlessly in one circumstance may fall short in another. Instead of building a web application based on the strengths and downsides of your selected frameworks, make sure you use frameworks that are aligned with the ultimate objective of your web application development process.
• SSR or CSR Approach
  When one of the aims for a frontend application is to improve SEO, Server-Side Rendering (SSR) along with Progressive Enhancement is a good choice. For applications in which SEO is no concern, client-side rendering (CSR) is an even more effective alternative.. Before you begin implementing Micro Frontend, you must first define your objectives so that you may select the procedures and frameworks that are most suited to achieving your goals. Micro-frontend Frameworks

You may decide to use Cam Jackson's micro-frontend technique. You may either come up with your own indigenous solution or borrow ideas from others. The frameworks specified in the Awesome Micro Frontends project are as follows:

• Mosaic — Project Mosaic is Zalando’s take on micro-frontends and is a complete framework for it.
• Single-spa: Canopy’s approach to micro-frontends is about composing multiple SPAs.
• OpenComponents: This is an open-source, “batteries included” micro-frontend framework.
• Polymer Project: This is Google’s take on building Web Components that still have some nice tooling.
• NUT: This is a framework born for micro-frontends, which is used internally in Netease. Currently, it supports Vue, React, etc.
• Podium: This is a server-side composition of micro-frontends.
• Piral: This is an open-source framework for next-generation portal applications using micro-frontends built with React.

There is no dominant micro-frontend approach yet. You can always pick up an existing solution to start with.

Micro-frontends add a new level of complexity to frontend development. We've seen the use case of breaking down an application into two parts: old code and newly developed code, on one end of the spectrum. On the other hand, we've seen the strategy of creating a slew of little micro-frontends, such as global types, time services, and i18n services. There are no hard and fast rules for determining which path is proper. It is entirely dependent on your use case and team chemistry. When developing micro-frontends, keep the following facts in mind:

• Do you wish to combine several micro-frontends into a single view?
• Would you like to merge many routes into a single micro-frontend?
• Would you like data and/or state to be exchanged across micro-frontends?
• Do you want to keep micro-frontends separate at runtime or combine them into a single application during development?
• Is your micro-frontend service domain-agnostic?
• Is your micro-frontend service going to be hosted in the cloud, on-premises, or both?

These considerations will influence how you design micro-frontends and how you select a micro-frontend framework. If you create modules properly, the more micro-frontends you have, the less coupling you'll have.

Conclusion

By separating code and encouraging independent development, Micro Frontends provide a reliable method for dividing the burden among multiple teams. These current solutions and frameworks are widely utilized because they serve as the backbone of this revolutionary approach to front-end development. If you're just getting started, it's a good idea to look at their use cases before deciding on the best frameworks for a large-scale project.