← Torna agli articoli Sviluppo & Architettura

Micro Frontend in Angular: Architettura e Deploy Indipendente tramite JAR

15 Feb 2026 Micro Frontends Architecture

Nelle grandi organizzazioni enterprise, la transizione dalle architetture monolitiche ai microservizi ha risolto molti problemi lato backend, introducendo team indipendenti, deploy disaccoppiati e maggiore scalabilità. Tuttavia, troppo spesso il frontend rimane un enorme monolite.

Oggi esploreremo una soluzione architetturale avanzata: l'utilizzo di Angular e Webpack Module Federation combinato con un paradigma di rilascio strettamente legato al backend. Scopriremo come e perché pacchettizzare i nostri Micro Frontend (MFE) direttamente all'interno di file .jar (es. usando Spring Boot).

Il Problema Architetturale e il Pattern "End-to-End"

Il concetto di Micro Frontend serve proprio a dividere l'applicazione UI in domini di business, permettendo a team separati di sviluppare, testare e rilasciare la propria porzione di interfaccia in totale autonomia.

Ma dove "vive" questo frontend in produzione? Molti team optano per hostare i MFE su CDN o bucket S3 (AWS). Questo va bene, ma in scenari enterprise complessi o in infrastrutture legacy/ibride, l'approccio migliore è spesso il pattern Self-Contained Systems (SCS) o Backend for Frontend (BFF).

In questo modello, il team responsabile del dominio "Ordini" gestisce un unico repository contenente sia il microservizio Java che il modulo Angular. Quando la pipeline CI/CD genera l'artefatto, viene creato un singolo file .jar contenente sia le logiche di business che i file statici compilati del frontend.

1. Configurazione di Angular (Module Federation)

Per abilitare la federazione dei moduli in Angular, il pacchetto standard de facto è @angular-architects/module-federation. Una volta installato nel progetto del nostro MFE "Ordini", configuriamo il webpack.config.js per esporre il modulo.


// webpack.config.js (Remote MFE)
const { shareAll, withModuleFederationPlugin } = require('@angular-architects/module-federation/webpack');

module.exports = withModuleFederationPlugin({
    name: 'ordersMfe',
    exposes: {
        './OrdersModule': './src/app/orders/orders.module.ts',
    },
    shared: {
        ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
    },
});

2. Pacchettizzazione del Frontend nel JAR (Maven)

Il vero "trucco" architetturale avviene durante la build del backend. Utilizziamo il frontend-maven-plugin per delegare a Maven l'installazione delle dipendenze npm e la build di Angular. Successivamente, copiamo la cartella dist/ all'interno delle risorse pubbliche del JAR.


<!-- pom.xml -->
<build>
    <plugins>
        <!-- 1. Build Angular -->
        <plugin>
            <groupId>com.github.eirslett</groupId>
            <artifactId>frontend-maven-plugin</artifactId>
            <executions>
                <execution>
                    <id>npm build</id>
                    <goals><goal>npm</goal></goals>
                    <configuration>
                        <arguments>run build:mfe</arguments>
                    </configuration>
                </execution>
            </executions>
        </plugin>

        <!-- 2. Copia i file generati nelle resources di Spring Boot -->
        <plugin>
            <artifactId>maven-resources-plugin</artifactId>
            <executions>
                <execution>
                    <id>copy-frontend</id>
                    <phase>generate-resources</phase>
                    <goals><goal>copy-resources</goal></goals>
                    <configuration>
                        <outputDirectory>${project.build.outputDirectory}/public/orders-ui</outputDirectory>
                        <resources>
                            <resource>
                                <directory>${project.basedir}/frontend/dist/orders-mfe</directory>
                            </resource>
                        </resources>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

3. Configurazione Lato Server (Spring Boot)

A questo punto, all'avvio del nostro JAR (es. sulla porta 8081), Spring Boot servirà automaticamente i file statici. Il file d'ingresso cruciale per l'orchestrazione è remoteEntry.js.

C'è però un dettaglio vitale: se il frontend Angular sfrutta l'History API del browser per il routing interno del modulo (es. /orders/history), il server backend riceverà richieste per percorsi che non conosce e restituirà un errore 404. È necessario implementare un Resource Handler per reindirizzare le richieste non mappate ai file statici del frontend, preservando lo stato lato client.

4. L'Orchestrazione (Shell App)

Infine, l'applicazione contenitore (la "Shell", solitamente deployata separatamente o sul gateway) caricherà a runtime il modulo esposto dal nostro JAR. Poiché ogni JAR risiede nel proprio ecosistema, il manifesto di federazione caricherà il modulo dinamicamente via URL.


// main.ts (Shell Application)
import { loadManifest } from '@angular-architects/module-federation';

// Carica la mappa dei micro frontend a runtime (può provenire da una API REST)
loadManifest({
    "ordersMfe": "https://api.tuodominio.com/orders-service/public/orders-ui/remoteEntry.js"
})
.catch(err => console.error('Manifest load error', err))
.then(() => import('./bootstrap'));

Pro e Contro di questo Approccio

I Vantaggi:

Deploy Atomico: Modifiche ad un'API backend e alla sua UI vengono rilasciate insieme. Niente più problemi di desincronizzazione tra client e server durante il deploy.
Cross-Origin Resource Sharing (CORS): Poiché l'UI del dominio viene scaricata dallo stesso server dell'API del dominio, le comunicazioni relative a quel dominio sono naturally same-origin.
Team Autonomi: Il team "Ordini" decide il proprio ciclo di rilascio senza bloccare il team "Utenti".

Gli Svantaggi:

Accoppiamento: Il ciclo di vita del frontend è vincolato ai tempi di build del backend Java, che di solito sono più lenti rispetto a una semplice pipeline npm + CDN.
Cache e CDN: Servire asset statici da un server Tomcat/Undertow (all'interno del JAR) è meno performante rispetto a servirli tramite una CDN globale edge, richiedendo accorgimenti infrastrutturali aggiuntivi (es. Cloudflare proxy).

In conclusione, integrare Micro Frontend in architetture JAR è una scelta estremamente potente per contesti enterprise fortemente "domain-driven", in cui i benefici della separazione organizzativa superano i trade-off legati all'infrastruttura di erogazione.

← Back to articles Development & Architecture

Micro Frontends in Angular: Architecture and Independent Deploy via JAR

Feb 15, 2026 Micro Frontends Architecture

In large enterprise organizations, the transition from monolithic architectures to microservices has solved many backend problems, introducing independent teams, decoupled deployments, and greater scalability. However, too often the frontend remains a huge monolith.

Today we will explore an advanced architectural solution: using Angular and Webpack Module Federation combined with a release paradigm closely linked to the backend. We will discover how and why to package our Micro Frontends (MFE) directly inside .jar files (e.g. using Spring Boot).

The Architectural Problem and the "End-to-End" Pattern

The concept of Micro Frontends serves exactly to divide the UI application into business domains, allowing separate teams to develop, test, and release their portion of the interface in total autonomy.

But where does this frontend "live" in production? Many teams choose to host MFEs on CDNs or S3 buckets (AWS). This is fine, but in complex enterprise scenarios or legacy/hybrid infrastructures, the best approach is often the Self-Contained Systems (SCS) or Backend for Frontend (BFF) pattern.

In this model, the team responsible for the "Orders" domain manages a single repository containing both the Java microservice and the Angular module. When the CI/CD pipeline generates the artifact, a single .jar file is created containing both the business logic and the compiled static frontend files.

1. Angular Configuration (Module Federation)

To enable module federation in Angular, the de facto standard package is @angular-architects/module-federation. Once installed in our "Orders" MFE project, we configure webpack.config.js to expose the module.


// webpack.config.js (Remote MFE)
const { shareAll, withModuleFederationPlugin } = require('@angular-architects/module-federation/webpack');

module.exports = withModuleFederationPlugin({
    name: 'ordersMfe',
    exposes: {
        './OrdersModule': './src/app/orders/orders.module.ts',
    },
    shared: {
        ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
    },
});

2. Packaging the Frontend in the JAR (Maven)

The real architectural "trick" happens during the backend build. We use the frontend-maven-plugin to delegate to Maven the installation of npm dependencies and the Angular build. Then, we copy the dist/ folder into the public resources of the JAR.


<!-- pom.xml -->
<build>
    <plugins>
        <!-- 1. Build Angular -->
        <plugin>
            <groupId>com.github.eirslett</groupId>
            <artifactId>frontend-maven-plugin</artifactId>
            <executions>
                <execution>
                    <id>npm build</id>
                    <goals><goal>npm</goal></goals>
                    <configuration>
                        <arguments>run build:mfe</arguments>
                    </configuration>
                </execution>
            </executions>
        </plugin>

        <!-- 2. Copy generated files to Spring Boot resources -->
        <plugin>
            <artifactId>maven-resources-plugin</artifactId>
            <executions>
                <execution>
                    <id>copy-frontend</id>
                    <phase>generate-resources</phase>
                    <goals><goal>copy-resources</goal></goals>
                    <configuration>
                        <outputDirectory>${project.build.outputDirectory}/public/orders-ui</outputDirectory>
                        <resources>
                            <resource>
                                <directory>${project.basedir}/frontend/dist/orders-mfe</directory>
                            </resource>
                        </resources>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

3. Server-Side Configuration (Spring Boot)

At this point, upon starting our JAR (e.g. on port 8081), Spring Boot will automatically serve the static files. The crucial entry file for orchestration is remoteEntry.js.

There is a vital detail, however: if the Angular frontend uses the browser's History API for the internal routing of the module (e.g. /orders/history), the backend server will receive requests for paths it does not know and will return a 404 error. It is necessary to implement a Resource Handler to redirect unmapped requests to the static frontend files, preserving the client-side state.

4. Orchestration (Shell App)

Finally, the container application (the "Shell", usually deployed separately or on the gateway) will load the module exposed by our JAR at runtime. Since each JAR resides in its own ecosystem, the federation manifest will load the module dynamically via URL.


// main.ts (Shell Application)
import { loadManifest } from '@angular-architects/module-federation';

// Load the micro frontend map at runtime (can come from a REST API)
loadManifest({
    "ordersMfe": "https://api.yourdomain.com/orders-service/public/orders-ui/remoteEntry.js"
})
.catch(err => console.error('Manifest load error', err))
.then(() => import('./bootstrap'));

Pros and Cons of this Approach

The Pros:

Atomic Deployments: Changes to a backend API and its UI are released together. No more desynchronization issues between client and server during deployment.
Cross-Origin Resource Sharing (CORS): Since the domain UI is downloaded from the same server as the domain API, communications related to that domain are naturally same-origin.
Autonomous Teams: The "Orders" team decides its own release cycle without blocking the "Users" team.

The Cons:

Coupling: The frontend lifecycle is tied to the Java backend build times, which are usually slower compared to a simple npm + CDN pipeline.
Cache and CDN: Serving static assets from a Tomcat/Undertow server (inside the JAR) is less performant compared to serving them via a global edge CDN, requiring additional infrastructural measures (e.g., Cloudflare proxy).

In conclusion, integrating Micro Frontends in JAR architectures is an extremely powerful choice for highly "domain-driven" enterprise contexts, where the benefits of organizational separation outweigh the trade-offs related to the delivery infrastructure.