Enterprise-scale software systems are often implemented by several cross-functional teams. To enable such teams to provide new features efficiently, it is desirable to minimize the need for coordination between them. This calls for a modularization that verticalizes the system into low-coupled areas individual teams can take care of.There are several possibilities for implementing such high-level modules (also called verticals). For instance, they can be implemented using a respective folder structure or in the form of several libraries in a Monorepo. Micro Frontends go one step further and designate a separate application for each vertical. This architectural style promises several advantages, such as a high amount of team autonomy, but it also comes with numerous challenges.The first part of this article provides a critical overview of the benefits and drawbacks of Micro Frontends in the space of single-page applications. The second part discusses how such an architecture can be implemented with Native Federation, a community project built upon web standards that provide close integration with the Angular CLI.Motivation Behind Micro FrontendsLike Micro Services, Micro Frontends promise several advantages, both technically and with respect to the organization. As applying Micro Frontend architectures results in several smaller applications, testing, performance tuning, and isolating faults in one part of the overarching system becomes more effortless, according to several sources.However, the increased team autonomy was the main reason for applying this architectural style in the numerous cases I was involved in as a consultant. Individual teams are not blocked by waiting for other teams and can deploy separately anytime. This might not be a significant concern in a vast number of projects. Still, as soon as we talk about multi-team projects in a corporate environment with long communication paths and decision times, this aspect quickly becomes vital for the project’s success.Teams can also make their own decisions that best fit their goals — architecturally and technology-wise. Mixing multiple client-side frameworks in the same application is considered an anti-pattern and should be avoided. However, it can help to create a migration path over to a new stack in the long run. The concern in corporate environments is that we find software solutions that usually outlive the average technology stackSince Micro Frontends result in separate build processes, combining them with incremental builds, where only changed applications need to be rebuilt, has a massive potential for build-time improvements. For instance, the well-known Nx build system provides this option. Interestingly, this feature can also be used without applying other aspects such as aligning teams with individual applications or separate deployments. There is debate about whether leveraging this tempting option automatically leads to micro frontend architectures.A system consisting of several smaller applications can provide further organizational advantages: It’s easier to onboard new members and scale the development by adding further micro frontends. Team autonomy also leads to faster release cycles.Challenges to keep in mindEvery architectural decision has consequences that need to be evaluated, and Micro Frontends are no exception. Besides the positive consequences outlined above, there are also several negative ones to consider.For instance, individually developed Micro Frontends can diverge in UI/UX, leading to an inconsistent appearance. Also, loading several applications increases the number of bundles that need to be downloaded, adversely affecting loading times and increasing the memory pressure.Splitting an application into low-coupled parts might be a best practice in general. However, it is often hard to define the boundaries between verticals clearly enough to implement them as individual applications. Also, while having several small applications at first glance simplifies the implementation, integrating them into an overarching solution brings additional complexity.This leads to one of the biggest challenges I have seen in practice: we are moving away from a compile-time integration towards a runtime integration. This has severe consequences because we cannot easily foresee problems that might arise when individually developed and deployed applications start interacting at runtime. Besides the chance of technical conflicts, we also have to see that the current generation of SPA frameworks has not been built with such an operation mode in mind.Instead, modern SPA frameworks, especially Angular, have been developed to focus on compile time optimizations. A powerful compiler leverages type checks to identify technical conflicts and emits efficient source code optimized for tree-shaking. Furthermore, the CLI in the Angular space provides a highly optimized build process. An off-label usage necessary for implementing Micro Frontends undermines some of these achievements.Angular Does Not Officially Support Micro FrontendsFor all the outlined reasons, the Angular team recommends checking if alternatives, like implementing the individual verticals in Monorepos, which can be compiled together, are suitable. For instance, Google adopted this approach years ago and manages all its products and libraries in a single Monorepo.Of course, there are also ways to compensate for the disadvantages outlined here, and some of them, like establishing a design system to help with a consistent UI/UX or lazy loading individual system parts, might be needed in general. More details on such compensation strategies can be found in this survey of more than 150 Micro Frontend practitioners.All architectural decisions have benefits and drawbacks and should be evaluated with those considerations if you are going to implement a solution. If such an evaluation reveals that Micro Frontends provide more advantages than alternatives for achieving your very goals, the following sections provide you a well-lit path for implementing this architectural pattern with Angular.Micro Frontends with FederationModule Federation is a popular technology for implementing Micro Frontends and sharing dependencies. Shipped initially with webpack 5, it comes with a tooling-agnostic runtime and provides compile-time integration into rspack, rebuild, and vite. Besides the usage of the vite dev server, these technologies are currently not supported by the Angular CLI. However, promising community solutions like @ng-rsbuild/plugin-nx and AnalogJS allow them to be used with Angular. Nx and my CLI-plugin provide an effortless integration.Module Federation enables an application to load parts of other separately built and deployed applications lazily. The loading application is referred to as the host; the integrated ones are called remotes:Federation, if permitted by the library version, can share dependencies like Angular or RxJS between the host and remotes. There are several configuration options for preventing version mismatches. Since MF can only decide which dependencies to share at runtime, tree-shaking for shared parts is not possible.To inform the host about the remotes and their shared dependencies, Module Federation creates a metadata file, the so-called remote entry, during the build. This file needs to be loaded into the host.Native FederationTo fully decouple the idea of Federation from specific bundlers, I started the project Native Federation several years ago. Its API surface is very similar to that of Module Federation. The focus is on portability and standards like ECMAScript modules and Import Maps. Its compile time acts as a wrapper around existing bundlers. For the communication with the bundler, it uses an exchangeable adapter:The integration into the Angular CLI directly delegates to Angular’s ApplicationBuilder that leverages the fast bundler esbuild, and is the foundation for several current features like partial hydration. Because of its architecture, Native Federation can also be ported to further builders or other innovations the CLI might provide in the long run.For integrating Micro Frontends built with Angular’s webpack-based builder, there is a bridging solution allowing the loading of such remotes into a Native Federation host. This solution enables the gradual adoption of the CLI’s new ApplicationBuilder and permits the sharing of dependencies between the two kinds of Federation. One of the features added recently is support for SSR and Hydration, which is vital for performance-critical applications like public portals and web shops.Native Federation for Angular is close to the CLI’s ApplicationBuilder, but its compilation mode is for shared dependencies differs. While it works well for packages that align with Angular’s Package Format, which is the case for all libraries built with the CLI, other libraries might provide some challenges, especially older ones that still use CommonJS or older conventions for providing metadata.Using Native Federation in AngularFor the setup Native Federation provides a schematic:ng add @angular-architects/native-federation --project mfe1 --port 4201 --type remoteThe switch type defines the kind of the application. Possible options are remote, host, and dynamic-host. The latter is a host configured with a configuration file (federation manifest) during application start. This manifest informs the application of the locations of the remotes and can be switched out by another manifest during deployment:{ "mfe1" : "http://localhost:4201/remoteEntry.json"}The key, in this case mfe1, is a short name the host uses to refer to the Micro Frontend. The value is the location of the remote entry with the metadata mentioned above. Alternatively, the manifest can be replaced by a service that informs the host of the current location of all deployed remotes and acts as a Micro Frontend registry.The schematic configures the Native Federation builder delegation to the ApplicationBuilder and creates a configuration file federation.config.js:const { withNativeFederation, shareAll } = require('@angular-architects/native-federation/config');module.exports = withNativeFederation({ name: 'mfe1', exposes: { './Component': './projects/mfe1/src/app/app.component.ts', }, shared: { ...shareAll({}), }, skip: [ 'rxjs/ajax', 'rxjs/fetch', 'rxjs/testing', 'rxjs/webSocket', // Add further packages you don't need at runtime ]});The configuration assigns a unique name to the remote or host and defines which dependencies to share. Instead of providing an exhaustive list of all the dependencies to share, the configuration uses the helper function shareAll, which adds all dependencies found in the project’s package.json. The skip list is used to opt out of sharing some of them or their secondary entry points.Remotes also define exposed EcmaScript modules that can be loaded into the shell. For this, the exposed node maps the paths of the modules to short names such as ./Component in the example shown.The schematic also adds code to initialize Native Federation to the main.ts. For the host, this code points to the federation manifest:import { initFederation } from '@angular-architects/native-federation';initFederation('federation.manifest.json') .catch(err => console.error(err)) .then(_ => import('./bootstrap')) .catch(err => console.error(err));After initializing federation, the file bootstrap.ts, also created by the schematic, is loaded. It contains the usual code for bootstrapping Angular, e.g., via bootstrapApplication when the application uses Standalone Components.To load a component or routing configuration exposed by a remote, traditional lazy loading is combined with Native Federation’s loadRemoteModule function:import { loadRemoteModule } from '@angular-architects/native-federation';export const APP_ROUTES: Routes = [ [...] { path: 'flights', loadChildren: () => loadRemoteModule('mfe1', './Component').then((m) => m.AppComponent), }, [...]];Here, mfe1 is the key defined in the manifest, and ./Component points to the respective exposed module in the remote’s federation configuration.More information on Native Federation can be found in this blog article and in the project’s readme, which also links to a tutorial.ConclusionMicro Frontends promise significant advantages for enterprise-scale applications, such as enhanced team autonomy and independent deployment. These benefits make this architectural style particularly appealing in multi-team corporate environments where streamlined communication and rapid development cycles are critical. Additionally, they support gradual migration to new technologies and optimize build times by leveraging incremental builds.However, these advantages come with trade-offs. Micro Frontends can lead to inconsistent UI/UX, increased load times, and complex runtime integrations. Defining clear vertical boundaries and managing inter-application communication add to the challenge. Furthermore, frameworks like Angular, designed for compile-time optimization, face limitations in runtime integration scenarios. The Angular team, therefore, recommends alternatives such as splitting an application into libraries managed within a Monorepo, which aligns better with Angular’s strengths in type safety and efficient compilation.Module Federation has emerged as a popular solution to address some challenges by enabling lazy loading and dependency sharing. Native Federation builds on these concepts with a focus on standards and portability. It provides a seamless integration into the Angular CLI and its performant esbuild-based ApplicationBuilder, which is also the foundation for advanced features like SSR and hydration.Together with this team at ANGULARarchitects.io, Manfred Steyer helps companies around the globe establish maintainable Angular-based Architectures. He is a trainer, consultant, and Google Developer Expert (GDE) and writes for O’Reilly, the German Java Magazin, windows.developer, and Heise Developer. Furthermore, he regularly speaks at conferences.Micro Frontends with Angular and Native Federation was originally published in Angular Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.