Micro-frontends offer a scalable solution for managing large applications by dividing them into smaller, independent pieces. This approach allows specialized teams to develop, test, and deploy sections of an application separately, improving efficiency and reducing complexity.
Micro-frontends apply microservices principles to front-end development, breaking down large applications into manageable parts. These parts, or micro-apps, can be independently developed and integrated, often through routing. For a deeper dive into micro-frontends, especially regarding module federation, we suggest our article on module federation.
Users see a unified application, while developers enjoy flexibility in deployment and serving options, including module federation for integrating micro-apps.
Micro-frontends allow using different frameworks or libraries for various application parts, offering flexibility but also posing challenges, such as team mobility. Tools like Single SPA or framework-specific solutions like Nx for Angular help integrate these technologies into a cohesive application. The aim is to independently build, test, and deploy each micro-app while ensuring a seamless user experience.
Large applications can suffer from lengthy test and build times, and slow local serving. Transitioning to micro-frontends by splitting the application into smaller parts can significantly alleviate these issues.
There are numerous methods for implementing micro-frontends, with various guides and resources available. Some focus on building micro-frontends from scratch, which is ideal for new projects expected to scale significantly.
This guide, however, concentrates on refactoring an existing application, potentially built using the Angular CLI, into shared libraries and individual apps. These components are then seamlessly integrated within the larger application, maintaining the unified user experience while enhancing development efficiency.
For our exploration into micro-frontends, we will utilize a sample application. This application, while not large or complex, incorporates several services that demonstrate how they can be integrated with each micro-app in a micro-frontend architecture.
The application's structure mirrors what one would typically get from creating a new project using the Angular CLI. Key elements include:
auth
) and user management (users
).The directory structure is as follows:
The goal is to refactor the services and models into libraries that can be shared across micro-apps. The feature modules, on the other hand, will be transformed into their individual apps. This approach ensures modularity and facilitates independent development and deployment of each feature.
The current routing setup in the application utilizes lazy loading, enhancing performance and user experience. Here's an extract showcasing the routing strategy:
This routing module demonstrates the use of guards (isLogged
and isNotLogged
) to manage access to different routes based on user authentication status, and dynamic imports for lazy loading of feature modules.
Migrating a complex application to a micro-frontend architecture can be challenging. To facilitate this process, clear steps and possibly additional tooling (for better dependency management) are essential.
Identify Independent Files: Start by pinpointing files that do not have dependencies but are used across services and feature modules. For example, in our sample application, this applies to the models
folder, which contains models used throughout the application but doesn't depend on any other files.
Create a New Library for these Files: Use Angular CLI to generate a library that will house these independent files. The command for this is:
This command results in the following actions:
projects
folder containing the models
library.ng-packagr
as a dependency.angular.json
and tsconfig.json
to include the new library.tsconfig.json
to avoid potential conflicts with npm modules. A suggested prefix is @@
, as npm module names cannot include double at signs.package.json
is registry-safe. Otherwise, you can choose a convenient name.models
folder into the new library. The generated library will contain default components, modules, and services, which can be removed. Place the user model file inside the lib
folder of the library.public-api.ts
file to export the appropriate content from the lib
folder.git mv
instead of operating system features for moving files. This ensures better tracking of changes by Git.The folder structure of the models
library should be organized for clarity and easy access.
Change Import Paths: Replace existing import paths with the new library path. For instance, change:
Ensure that the path matches what is specified in tsconfig.json
.
Resolving Errors: Initially, you may encounter errors due to the library not being built. Resolve this by running:
This command compiles the models
library, allowing TypeScript to correctly reference @@models
.
After successfully migrating independent code into libraries, the next step involves tackling dependent code that can also be isolated. Continuing with our example, we'll focus on migrating the auth
service, including its guards, into a separate library. This process mirrors the steps taken for the models
library.
Use Angular CLI to create the auth
library with the command:
Remove the default content from the lib
folder and transfer all contents of the auth
folder into it. Update the public-api.ts
file to reflect these changes.
The public-api.ts
should look something like this:
Compile the auth
library using Angular CLI:
Change the application's import statements to use the new auth
library.
Congratulations are in order! Parts of your application have been successfully migrated into libraries. This not only keeps the application running but potentially speeds it up, as Angular doesn't need to rebuild the entire application. You now have several libraries with isolated testing and building, suitable for larger applications where components, services, pipes, and other elements are shared.
For more complex applications, consider using ng-packagr's Secondary Entrypoints feature to group common items like components or services. This requires additional configuration adjustments.
Having learned to package libraries, we now turn to migrating a feature module into its own application.
In our example, the Login
feature module is selected for migration. Ensure that all shared artifacts used by this module are already in their respective libraries. Other services, like the users
service, can be migrated later.
Use Angular CLI to create the login
application:
The --routing
flag is essential for navigation within the app.
Test the newly created application with:
If the main application is running, you may need to use a different port.
Transfer the Feature Module: Instead of replacing files as done with libraries, create a feature
folder in the src
of the new application and move the login
folder into it.
Update Routing: Modify the app-routing.module.ts
of the login
application to serve the Login
module at the root route.
Adjust the AppComponent: Ensure the app.component.html
of the login
app contains a <router-outlet></router-outlet>
tag for routing to function correctly.
Initially, the new application might appear unstyled. Copy the styles.scss
file from the main application to the new one to resolve this. Future posts will delve into sharing styles across applications.
If done correctly, the login
application should now be running independently, styled, and functional, marking a significant step in your journey towards a fully implemented micro-frontend architecture.
After setting up the Login
application as a standalone entity, the next critical step is integrating it with the main application. This involves building the Login
app as a library and importing it using the existing lazy load feature in the main module.
angular.json
angular.json
, duplicate a library configuration, placing it under the login
configuration for better organization. Rename the key to login-lib
and update references (such as root
, sourceRoot
) to point to the login
application.The updated configuration should be adjusted to reflect the specific paths and settings of the login
application.
ng-package.json
: This file is essential for instructing ng-packagr
on how to package the application. Copy an existing ng-package.json
file from another library into the root folder of the Login
application. Update the dest
key to "../../dist/login-lib"
to specify the build output directory.public-api.ts
: This file, different from typical library setups, should be created under the src
folder. It should export only the Login
feature module:package.json
: Copy a package.json
from another library to the root of the Login
application, ensuring to update the project name.This process compiles the Login
module as a library.
Update tsconfig.json
: Add a new path mapping for the login-lib
in tsconfig.json
, pointing to "dist/login-lib"
. This step is crucial for TypeScript to locate the library correctly.
Modify Application Routing: In app-routing.module.ts
, update the lazy loading path to use the new library:
With these changes, you can serve the application as usual. The Login
module, now a separate project, should function seamlessly within the main app.