Investigating Benefits and Limitations of Migrating to a Micro-Frontends Architecture (2407.15829v1)

Abstract: [Context] The adoption of micro-frontends architectures has gained traction as a promising approach to enhance modularity, scalability, and maintainability of web applications. [Goal] The primary aim of this research is to investigate the benefits and limitations of migrating a real-world application to a micro-frontends architecture from the perspective of the developers. [Method] Based on the action research approach, after diagnosis and planning, we applied an intervention of migrating the target web application to a micro-frontends architecture. Thereafter, the migration was evaluated in a workshop involving the remaining developers responsible for maintaining the application. During the workshop, these developers were presented with the migrated architecture, conducted a simple maintenance task, discussed benefits and limitations in a focus group to gather insights, and answered a questionnaire on the acceptance of the technology. [Results] Developers' perceptions gathered during the focus group reinforce the benefits and limitations reported in the literature. Key benefits included enhanced flexibility in technology choices, scalability of development teams, and gradual migration of technologies. However, the increased complexity of the architecture raised concerns among developers, particularly in dependency and environment management, debugging, and integration testing. [Conclusions] While micro-frontends represent a promising technology, unresolved issues still limit their broader applicability. Developers generally perceived the architecture as useful and moderately easy to use but hesitated to adopt it.

• The paper demonstrates that migrating from a monolithic system to micro-frontends enhances component reuse and parallel development but introduces complex dependency management.
• Using action research, the study employs client-side composition with Module Federation to share libraries while revealing challenges in integration testing and maintainability.
• The evaluation via the Technology Acceptance Model indicates perceived benefits and ease of use, yet developers show hesitation towards full adoption due to added architectural complexity.

This paper investigates the practical benefits and limitations of migrating a real-world monolithic web application to a micro-frontends architecture from the developers' perspective. The paper employs an action research methodology, involving diagnosis of the existing system, planning the migration, implementing the micro-frontend architecture (intervention), and evaluating its impact through a workshop with developers.

The research aims to answer two main questions:

1. What are the benefits and issues of the micro-frontends architecture compared to a monolithic one, particularly regarding the development process and component reuse?
2. What is the acceptance level of the micro-frontends architecture among developers, assessed using the Technology Acceptance Model (TAM)?

Background on Micro-Frontends:

Micro-frontends decompose web applications into smaller, independently deliverable frontend units. Key technical decisions include:

• Splitting: Vertical (one micro-frontend at a time, often domain-based) or horizontal (multiple sections displayed simultaneously).
• Composition: Client-side (in browser), edge-side (at CDN), or server-side (compile or runtime).
• Routing: Server-defined, application shell-defined (client-side), or CDN-managed.
• Communication: Browser features (Web Storage, query strings) or event bus (for client-side).

The paper lists known benefits (e.g., technology diversity, autonomous teams, independent deployment, better testability, fault isolation, scalability, faster onboarding, future-proofing) and issues (e.g., increased payload, code duplication, dependency management, UX consistency, monitoring complexity, architectural complexity, governance, knowledge silos, environment differences, update risks).

Research Context and Methodology:

The paper was conducted on a system developed by a research institute for an oil and gas company, supporting geophysical processing. The application helps geophysicists manage algorithm workflows. Ten developers from two scrum teams, experienced with the monolithic version, participated.

The action research comprised:

1. Diagnosis: Analysis of the existing Angular 12 application revealed high component interaction and shared model dependencies, making parallel development difficult. Interviews with developers highlighted issues with common libraries, slow test pipelines, duplicated test code, and challenges in onboarding and code reusability.
2. Planning: Micro-frontends were chosen to address the need for parallel development and component reuse. A rationale was developed by analyzing potential benefits and issues in the system's context. For instance, using the same framework (Angular) across micro-frontends was planned to mitigate issues like increased payload and dependency complexities. A common UI library was proposed for UX consistency.
3. Intervention:
   • Splitting: A horizontal split was chosen due to shared components and to promote reuse.
   • Technology: All micro-frontends continued using Angular.
   • Composition: Client-side composition using Module Federation (via webpack) was implemented. This allowed defining shared libraries to be loaded only once.
   • Routing: Handled by the application shell, associating remote modules to router URLs.
   • Communication: An event emitter (Angular service) was injected into each micro-frontend. URL-encoded variables enabled direct page access.
   • Implementation: The application was divided into four main micro-frontends (from an initial plan of five):
     • project-selection-microfrontend: Lists projects.
     • project-info-microfrontend: Tabs for editing project data.
     • pipeline-microfrontend: Tree graph of phase sequences.
     • phase-parametrization-microfrontend: Parameterizes and executes phases. (The execution-table-microfrontend was deemed unnecessary as its view-only functionality was covered elsewhere.)
   • Auxiliary Libraries:
     • Common Libraries: microfrontends-core (environment/session services), microfrontends-ui (UX consistency), flow-in-memory-db (mock backend for development).
     • Feature Libraries: Categorized by application data (projects, files, phases), containing models, utility components, and services for data access and modification. The architecture diagram shows these libraries and micro-frontends, highlighting their dependencies.

       +----------------------+ +----------------------+ +------------------------+ +---------------------------+ | project-selection-mf | --> | microfrontends- | --> | microfrontends-core | --> | shell application | +----------------------+ | project-library | +------------------------+ +---------------------------+ +----------------------+ | microfrontends-ui | +----------------------+ | microfrontends-file-library| | project-info-mf | -------------------------------> +------------------------+ +----------------------+ +----------------------+ +------------------------+ +----------------------+ --> | microfrontends- | --> | flow-in-memory-db | | pipeline-mf | | phase-library | +------------------------+ +----------------------+ +----------------------+ +---------------------------+ | phase-parametrization-mf | +---------------------------+

       (Simplified representation of Figure 3 from the paper)
4. Evaluation: A workshop was conducted with developers:
   • Presentation (45 min): Overview of micro-frontends and the migrated architecture.
   • Practical Application (45 min): Developers added a new form field to the project-info-microfrontend.
   • Focus Group (60 min): Discussion of benefits and issues, rating statements on a Likert scale. A TAM questionnaire was also completed.

Evaluation Results:

Focus Group (Benefits and Issues - RQ1):

• Benefits Generally Agreed Upon:
  • B1 (Different Technologies): Unanimous agreement, but with a note on maintenance cost.
  • B7 (Faster Onboarding): Partial agreement; focused scope helps, but overall integration can be challenging.
  • B10 (Future Proofing): Agreement on flexibility for gradual migration, but concerns about replicating changes and compatibility.
• Benefits with Mixed Opinions/Concerns:
  • B2 (Autonomous Teams), B3 (Independent Deployment): Divided opinions; alignment still crucial.
  • B4 (Easier Testing): Mixed; simpler unit tests but complexities in integration testing and maintenance.
  • B5 (Fault Isolation): Varying perspectives, depends on granularity.
  • B6 (Scalability): Potential exists, but challenges with communication and team division.
  • B8 (Initial Load Time), B9 (Performance): Not necessarily improved; depends on composition, division, and dependency management.
  • Q11 (Code Reusability): Potential if a micro-frontend is used across apps, but uncertain for reuse within the same app compared to monoliths.
• Issues Generally Agreed Upon:
  • I1 (Increased Payload Size): Consensus due to duplicated dependencies/code.
  • I2 (Code Duplication): Concerns, especially for scripts, configs, deployment code.
  • I3 (Dependency Management): Notable concerns about complexity, version conflicts, and updating shared dependencies.
  • I4 (UX Consistency): Challenges in maintaining consistency; proactive measures needed.
  • I5 (Debugging Complexity): More laborious; often requires debugging each micro-frontend separately and their interactions.
  • I8 (Knowledge Fragmentation): Partial agreement; micro-frontends can exacerbate this.
  • I9 (Environment Differences Risk), I10 (Bugs to Production Risk): Agreement on increased risk due to environmental complexity, dynamic updates, and isolated work.
• Issues with Mixed Opinions/Concerns:
  • I6 (Increased Complexity): Wide variation; aspects like dependency management, deployment, and testing add complexity, but code-level complexity might decrease with good architecture.
  • I7 (More Team Coordination): Some believe independence might increase coordination needs for broader changes; others see coordination as always necessary.

Technology Acceptance Model (TAM) Results (RQ2):

• Perceived Usefulness (Q1-Q4): Responses ranged from neutral to positive. Developers generally saw the architecture as potentially improving performance, productivity, and effectiveness.
• Perceived Ease of Use (Q5-Q8): Responses also ranged from neutral to positive. Learning and using micro-frontends was seen as moderately easy.
• Intention to Adopt (Q9): Showed a slightly negative trend, with most responses neutral. This suggests hesitation despite perceiving usefulness and moderate ease of use, possibly because their current multi-repository setup already offers some independence.

Discussion Highlights:

• Managing Dependencies vs. Duplicating Code: A key challenge. Replicating some code (models, services) across micro-frontends could simplify repository management but increases code maintenance. Better tools for version tracking or managing replicated code are needed.
• Client-side Composition vs. Compile-time Composition: The chosen client-side approach (Module Federation) offered deployment independence but added infrastructure complexity (serving micro-frontends at distinct URLs, version management). Compile-time composition might have been simpler for this specific context.
• Choosing the Split and Structuring: The split type (horizontal vs. vertical) significantly impacts dependencies, complexity, and team autonomy. Horizontal splits might enhance reusability but can increase complexity.
• Integration Tests: Current end-to-end tests (Cypress) involve significant code duplication. Replicating this for each micro-frontend would increase codebase and maintenance, and prolong build times. Guidelines for testing micro-frontends to minimize duplication and improve pipeline speed are needed.

Conclusions:

Micro-frontends offer flexibility in technology choices, potential for improved team autonomy, scalability, and gradual technology transitions. However, they introduce significant complexity in dependency management, debugging, integration testing, and maintaining UI/UX consistency. While developers in this paper perceived the architecture as useful and moderately easy to use, they hesitated to adopt it, primarily due to these unresolved complexities. The benefits might not have outweighed the perceived increase in complexity in their specific project context. The paper suggests that future research should explore more implementation approaches and focus on streamlining development by addressing issues like dependency management and integration testing.