DEV Community

Cover image for Building a Large Scale Micro-frontend Application.

Posted on • Originally published at

Building a Large Scale Micro-frontend Application.

The complexity of web applications makes maintaining traditional monolithic architectures more challenging. Micro-frontends have emerged as a promising solution to these challenges. It allows us to break up the front end of a web application into independent pieces that we can use easily. This approach allows for increased scalability, better maintainability, and improved performance.

This article will examine what is necessary to build a large-scale micro-frontend application.

What are micro-frontends?

In web development, micro-frontends are a relatively recent architectural pattern. Its idea is like that of microservices used for back-end development. Micro-frontends involve disassembling a web application's front-end into more manageable, smaller sections. We can develop and deploy each disassembled micro-frontend independently. As a result, various teams can work independently on various application components.

Micro-frontends can communicate through custom elements and custom events. Both act as standardized channels for interaction between micro-frontends. We can use custom elements to define reusable UI components across micro-frontends. For instance, we can define a custom element in one micro-frontend to house a complex UI component. We can then reuse the custom element on several micro-frontends when needed. It makes it easy to reuse and integrate into different areas of our front-end application.

When do we use micro-frontends?

Micro-frontends are appropriate for complex, large-scale applications. Applications requiring scaling and evolution over time have complex requirements and need teamwork. Consider an e-commerce platform, for instance, with user interfaces for buyers and sellers. Each of these portals will have its unique features and requirements. We can use micro-frontends to develop each portal independently. It will ensure that each portal gives the best user experience and adapts to its specific use case.

Benefits of using micro-frontends

The benefits of using a micro-frontend approach include the following:

  • Flexibility: We can develop and deploy micro-frontends independently using various programming languages. For example, consider an e-commerce website with many micro-frontends, such as shopping carts. We could use Node.js for the payment gateway and React to create the product catalogue. This approach allows development teams to select the ideal tools for every micro-frontend.
  • Easier maintenance: As micro-frontends are independent, we can update and maintain them independently. As a result, it is easy to update one application component without affecting others. For example, a developer can update a shopping cart if they find a bug without affecting other parts.
  • Scalability: Scalability enables enhanced application traffic handling without causing slowdowns or crashes. Micro-frontends work independently, so scaling up or down doesn't affect other application parts. The entire application does not go offline if one of the micro-frontends fails.
  • Better collaboration: Micro-frontends help improve teamwork. Breaking front-end web applications into smaller parts improves collaboration between development teams. It becomes simpler to design several application components without interfering with one another.

Key parts of scalability

Scalability plays a crucial role in creating and maintaining software programs and systems. It refers to a program's ability to handle a spike in traffic or user demand without slowing down. Micro-frontend enables scalability by breaking the front end down into smaller units. Then, based on their unique needs, we can scale each micro-frontend independently. It ensures that the application user has a seamless user experience.

The vital components of scalability are as follows:

  • Loose coupling
  • Front-end discovery
  • Dependency sharing

Loose coupling

Loose coupling is an essential concept for a successful micro-frontend architecture. It allows micro-frontends to interact without relying on one another's architecture or codebase. As a result, we can create, test, and deploy them without affecting the rest of the application. It allows for more flexibility and scalability when developing complex web applications. It also enables developers to create more modular and easier-to-maintain applications.

Piral, an open-source micro-frontend framework, allows us to create independent front-end modules. Its shared runtime environment enables us to achieve loose coupling between micro-frontends. It is also responsible for handling the loading and unloading of the micro-frontends. Get started creating independent front-end modules with Piral by reading the Piral documentation.

Front-end discovery

Front-end discovery enables effective and dynamic runtime discovery of micro-frontends. This technique allows us to discover and integrate micro-frontend without requiring explicit configuration. As a result, micro-frontends are scalable compared to traditional front-end architectures.

Traditional front-end modules are tightly coupled, i.e., are highly interdependent. It is difficult to maintain and scale since a change in one module influences the others. But with front-end discovery, the micro-frontends are all hosted in independent servers. It allows each micro-frontend to publish its metadata. We can then use this metadata to discover and integrate with other modules at runtime. For micro-frontend delivery, we can use tools like Piral's cloud service. It helps facilitates deploying, sharing, and managing micro-frontends across many applications. For more information on Piral's cloud service, click here.

Dependency sharing

Dependency sharing allows several micro-frontends to share dependencies, such as libraries and frameworks. A shared library's latest version automatically updates all micro-frontends using it. It helps optimize performance, reduce development time, and ensure application consistency.

A micro-frontend architecture offers several options for sharing dependencies, including:

  • Centrally shared dependencies
  • Distributed shared dependencies

Centrally shared dependencies rely on a standard functionality provided by a central module. Micro-frontends can thus retrieve shared dependencies from the centralized location when necessary. These dependencies include UI components or shared libraries. Updates or edits to the centralized dependency affect all micro-frontends that use it. Using a centrally shared dependency ensures consistency and keeps our application up-to-date. However, managing and coordinating shared dependencies is crucial to preventing system breakdowns.

In contrast, distributed shared dependencies allow each micro-frontend to manage its dependencies independently. Its hosting is not centralized but distributed between several servers and systems. Using this approach leads to more autonomy and flexibility for each micro-frontend. However, managing dependencies and guaranteeing compatibility between micro-frontends also takes more effort. Choosing between both dependencies in micro-frontends depends on our project's specific needs. To learn more about dependency sharing, click here.

Piral uses Pilets to share dependencies across micro-frontends. Pilets are packages containing a single micro-frontend with several components and shared dependencies. It uses "import maps" as a sharing mechanism for dependencies.

Here are the steps to use Piral for dependency sharing:

Declare potentially shared dependencies via the Pilet's package.json:

      "name": "my-pilet",
      "version": "1.0.0",
      "importmap": {
        "imports": {
          "lodash": "./node_modules/lodash/index.js"
Enter fullscreen mode Exit fullscreen mode

Installing the dependency locally on our computer as a "dev dependency" is crucial. It makes no difference, even if we reference it from a remote location like CDN.

  npm i lodash --save-dev
Enter fullscreen mode Exit fullscreen mode

At this point, we can use the shared resource in our code just like any other dependency:

      // MyPage.tsx
    import * as React from 'react';
    import { partition } from 'lodash';

    const partitions = partition([1, 2, 3, 4], n => n % 2);

    export default () => (
          {, i) => <li key={i}>Partition {i + 1} with {p.length} elements</li>)}
Enter fullscreen mode Exit fullscreen mode

To learn more about Pilets, visit Piral's documentation.

Tools for solving scalability

Most applications will likely experience scalability challenges as user demands and workloads increase. Tools for solving scalability help us develop applications that can handle increased workloads. These tools help optimize resource usage, improve availability, and enhance system efficiency.

How do Single-SPA and module federations tackle the problem?

Single-SPA and module federation are potent tools for building scalable micro-frontends. Single-spa provides a framework for building a modular front-end application. It allows lazy loading of micro-frontends, which helps improve the application's performance. In contrast, module federation enables communication and dependency sharing between different micro-frontends. It reduces code duplication, which can help with scaling an application.

Despite both technologies' strengths, they need help to solve all scalability problems. Developers still need to consider their overall micro-frontend design to ensure scalability. These include state management, communicating with micro-frontends, and general performance. Also, developers should consider load balancing and caching while dealing with increased traffic. For more on Single-SPA and module federation, click here.

How does Piral tackle the problem?

Piral offers many features that help solve the scalability issue in micro-frontend applications. It enables developers to discover and load dynamic micro-frontends, share dependencies, and more.

Building a large-scale micro-frontend application has many issues, including managing dependencies. It causes increased code size, slower load times and difficulty maintaining the application. Piral helps solve this problem by allowing developers to share dependencies between micro-frontends. It enables applications to reuse codes and makes them easier to maintain.

Discovering and loading micro-frontends is another difficulty in developing a micro-frontend application. Using Piral's dynamic loader, users can find and load micro-frontends on the go. It reduces page load time by loading only the required micro-frontends at runtime. Developers do not need to restart the application to add or remove micro-frontends.

Finally, Piral assists in maintaining loose coupling between various application components. Through its messaging system, many micro-frontends can communicate without relying on one another.

Similarities between Single-SPA and Piral

Single-SPA and Piral frameworks have some of the following similarities:

  • Cross-framework support: Both frameworks support multiple front-end frameworks like React. It gives developers the flexibility to use the tools they are more comfortable with.
  • Module loading: Both frameworks allow for the dynamic loading and unloading of modules. It means we can load and unload modules as the application requires on the fly without a full page reload. It helps reduce overall application load time and enhances the application's performance.
  • Lazy-loading: Both frameworks support the lazy loading of micro-frontends. They load only the required micro-frontends on demand when a user moves to a particular route. It helps to optimize the loading speed and performance of the application.

Difference between Single-SPA and Piral

Both Single-SPA and Piral are frameworks for building micro-frontends. However, they differ in a few key ways, such as:

  • Architecture: A single runtime and router manage all micro-frontends' lifecycle in Single-SPA. The router loads and unloads all micro-frontends dynamically from a single entry point. It ensures that the micro-frontends communicate with each other and operate smoothly. Piral, in comparison, allows several routing and runtime options and is more flexible. It gives developers more flexibility in structuring and managing their micro-frontends. It provides several app shell options that we can use to manage our micro-frontends. We can implement these app shells using various frameworks like React and Vue.js.
  • Ecosystem: Single-SPA has a larger ecosystem and has been around longer than Piral. In contrast, Piral is a newer framework still growing its ecosystem. As Piral grows, its ecosystem will expand and become more robust. Its unique features and growing developer community make it ideal for building micro-frontends.
  • Development experience: Piral provides more comprehensive tools and features than Single-SPA. The Piral command-line interface, for example, simplifies many aspects of the development process. It helps developers to scaffold, build, and deploy micro-frontends. Also, Piral provides a plugin system for customizing, integrating, and adding new features. Single-SPA, in contrast, offers a more straightforward API for loading and unloading micro-frontends. Despite its lightweight, easy-to-understand nature, it isn't as flexible and extensible as Piral.

Single-SPA and Piral are potent tools for building scalable web applications. Choosing between both depends on our project's specific needs, expertise and preferences.


Micro-frontend applications have become increasingly popular among developers thanks to their many advantages. It helps create modular and maintainable applications capable of handling complex business needs. As with any technology, implementing micro-frontends poses challenges, such as ensuring consistent APIs. But, with tools like Piral, developers can easily create and scale micro-frontend applications.


We will find the following resources helpful:

Top comments (5)

webjose profile image
José Pablo Ramírez Vargas

I just made single-spa easier with vite-plugin-single-spa, a Vite plug-in that sets everything up in regular Vite + XXX projects.

I am interested in feedback from the single-spa developer community, so please test this out if you have the time. Thanks!

tamusjroyce profile image

You mean, big ball of mud. The last monolith was really Linux Kernel 1.2 where the whole monolith debate came from.

Great article. Different platform than webpack or rspack. Great to have alternatives that work together.

cesscode profile image

Thanks for reading

st9970_dc9 profile image

Great article.! thanks for sharing your thoughts!

cesscode profile image

Thanks for reading