Microfrontend architecture is an approach to designing and developing large-scale enterprise frontend applications by breaking them down into smaller, autonomous, and manageable parts.
Each part or microfrontend is developed separately, then either compiled and distributed as a single unit (build-time microfrontend) or domain-hosted and assembled at request (run-time microfrontend), allowing for greater flexibility and scalability.
Initially, using the domain-driven design (DDD) methodology, the Microfrontend architecture breaks the application into business concerns and calls each one a microfrontend.
Subsequently, each microfrontend is then assigned to a team that specializes and focuses on in end-to-end cross functional development including API integration, user interface, analytics, offline capabilities, etc. Implementation specifics and considerations may vary.
Microfrontend architecture can be applied to both mobile and web applications. In these two blogs we will differentiate and explain the strategies for applying microfrontend to mobile and web applications.
Microfrontend in Mobile Applications
Microfrontend in Mobile Applications lean towards build-time architectures, and they can be developed with either native or hybrid technologies.
This approach involves developing each microfrontend independently, yet during the compilation, they are bundled into a single monolithic application for deployment and delivery.
This hybrid strategy combines the benefits of modularization, which expedites the development, with the efficiency of downloading and executing a single binary.
Module Based Architecture
- Strategy:
- The main project is referred to as “Shell” responsible for navigation and injecting cross-cutting concerns to each microfrontend. Each subproject or submodule is a microfrontend representing a specific feature or screen within the app.
- Shell loads and unloads microfrontends as the user navigates between screens, while simultaneously injecting common dependencies like analytics etc. to each.
- Shell also acts as a message bus for inter-microfrontend communication. Each microfrontend is responsible for its own sub-navigation, updates to its focused areas and testing.
- Implementation:
- iOS: Add subprojects (Frameworks) for each Microfrontend in the XCode Workspace.
- Android: Add a submodule to an existing Android application.
- Flutter: Add a package with its own pubspec.yaml as a dependency on the root or base project.
- React Native: Develop each microfrontend in separate projects as UI and API Integration libraries and imported to the main app.
Code Sharing and Reusability
-
- Shared components and libraries: Identify common components, utilities, or libraries that can be shared across different modules via dependency injection from the shell.
- Package management: Utilize package managers like CocoaPods and Swift Package Manager for iOS, Jetpack for Android, Dart packages for Flutter, npm or yarn for React Native to manage dependencies and shared code between modules.
Independent Release Cycles
-
- Strategy: Microfrontend in mobile applications allows independent release cycles. Teams can update and release individual modules without affecting the entire application.
- Implementation: Continuous integration and delivery processes can be established for each module, allowing for quicker and more frequent updates to specific parts of the mobile app.
Native and Hybrid Approaches:
-
- Strategy: Mobile applications may leverage native or hybrid approaches when implementing Microfrontend. Native modules may use platform-specific technologies, while hybrid modules can be developed using cross-platform frameworks.
- Implementation: The choice between native and hybrid approaches depends on factors like performance requirements, development speed, and the need for platform-specific features.
In the second part of this blog series, our author takes a look at the microfrontend in web applications.