A Catalog of Micro Frontends Anti-patterns

Anti-patterns are recurring design practices, choices, or solutions to common problems. Despite appearing reasonable and effective, they lead to negative consequences and undermine the system’s overall quality [14]. An anti-pattern is similar to a pattern, but instead of providing a practical solution, it offers an approach that appears to be a solution on the surface. However, it ultimately leads to more problems [15]. While a problem and its optimal solution characterize patterns, anti-patterns involve two solutions [16]. The first solution is a commonly occurring solution that generates overwhelmingly negative consequences. The second solution is a commonly occurring method in which the anti-pattern can be resolved and reengineered into a more beneficial form.

There are three forms to define anti-patterns [15, 10]: (1) Degenerative Form: the most basic one is a textual description without any structure, template, or separate content sections for various aspects of the pattern; (2) Mini-AntiPattern: a more structured approach, consists of name, problem, and solution; and (3) Formal Definitions: including the Full AntiPattern Template and the Laplante-Neil Structure, consists of multiple fields detailing various dimensions of the anti-pattern. In this paper, we will use the Mini-AntiPattern format due to its simplicity in proposing new anti-patterns while maintaining a structured approach.

Microservice is an architectural style presented as an alternative to monolith architectures [17]. Lewis and Fowler [3] first defined Microservice as an approach to developing a single application as a suite of small services, each running in its process and communicating with lightweight mechanisms. A service is a self-contained, loosely coupled software unit designed to perform a specific business function. This modular design ensures each service has a well-defined and focused set of responsibilities, promoting maintainability and scalability [4]. Microservices enable technology heterogeneity, autonomous teams, independent deployment, independent scale, independent testing, and easy experimenting and adoption of new technologies [18, 19].

Microservices anti-patterns are well-defined in scientific literature. Some of them can be correlated with corresponding micro frontends anti-patterns, owing the shared characteristics between both architectural styles: Cyclic Dependency [9, 20, 21, 14, 22], Hub-like Dependency [14], The Knot or Knot Service [21, 14], Microservice Greedy [9, 21, 14], Nano Service [20, 21, 14, 22], Mega service [9, 20, 14, 22], Wrong Cuts [9, 21, 14, 22], No Api Versioning [9, 20, 14, 22], No DevOps Tools or Continuous Integration (CI) / Continuous Delivery (CD) [9, 20, 14], Microservices as the goal [9], Lack of Microservice Skeleton [9] and Golden hammer [22]. These anti-patterns formed the basis for proposing micro frontend anti-patterns.

The term “Micro Frontend” was first coined by ThoughtWorks in 2016 [23] as an architectural style inspired by microservices architecture. The main idea is to decompose a monolithic frontend application into smaller parts that can be developed, deployed, and updated independently, promoting greater flexibility and maintainability [6, 7]. Micro frontend (MFE) can also be considered an organizational approach. The application is divided into vertical slices built from the database to the user interface and run by a dedicated team [5]. In an MFE architecture, the web application integrates different features or business sub-domains, and each software team should have only one domain to handle [7]. Many companies adopted the MFE architecture, such as SAP, Springer, Zalando, NewRelic, Ikea, Starbucks, and DAZN [8].

MFEs share the main principles, benefits, and issues of microservices [23, 8, 6]. The motivations are development scalability and codebase growth, and the benefits include support for different technologies, autonomous cross-functional teams, development, deployment, management independence, and better testability. However, the primary drawbacks are increased payload size, complex monitoring and debugging, state management, and duplicated code [7].

Each MFE implements a set of screens and fragments. Fragments are reusable User Interface (UI) components that can be combined to form screens across different MFEs [5]. Some fragments might need context information, but the team, including the fragment in their MFE, does not have to know the fragments’ state or implementation details. The MFEs must integrate a coherent application to deliver a unified User Experience (UX) [5]. Achieving this requires developers to make informed decisions regarding the composition, communication, and routing between the MFEs.

The first decision is about composition, the process of requesting the fragments and putting them in the correct slots in a screen [5]. There are three approaches to composing MFEs: Server-side, Edge-side, and Client-side.

1. 1.

   Client-side Composition (CSC): An application shell loads MicroFrontends inside itself. An application shell is technically represented by an HTML file always present during the user session containing a small JavaScript code for loading and orchestrating different MFEs [8, 7, 5]. CSC needs MFEs-specific frameworks [24], such as single-spa [25], qiankun [26] and Garfish [27], or with frameworkless technologies like Webpack, Module Federation, iFrames, and web components.

2. 2.

   Edge-side Composition (ESC): The web page is assembled at the Content Delivery Network (CDN) level, using an XML-based markup language called Edge Side Include (ESI) [7]. One of the drawbacks of this implementation is that ESI is not implemented in the same way by each CDN provider, which can lead to many refactors and new logic implementation.

3. 3.

   Server-side Composition (SSC): The origin server is composing the view by retrieving all the different MFEs and assembling the final page. It can happen at runtime or compile time [7, 5]. It is the simplest approach because it enables the development of MFEs as packages [24]. However, this approach does not meet some of the main principles of MFE, such as technology agnosticism and independent delivery.

Once the fragments are composed into a screen, the team needs to decide how the MFEs will communicate with each other. Effective communication outlines how the screen and fragments interact to deliver a seamless user experience (UX) [8]. Geers [5] defines three primary forms of communication: Parent to Fragment, Fragment to Parent, and Fragment to Fragment.

1. 1.

   Parent to Fragment Communication: A change in the screen is propagated down to one or more fragments so they can update themselves. This form is also called Parent-child Communication.

2. 2.

   Fragment to Parent Communication: A change on a fragment sends a message to the screen so it can update itself. This form is also called Child-parent Communication.

3. 3.

   Fragment to Fragment Communication: A change on a fragment sends a message to one or more fragments composed on the same screen. This form is also called Child-child Communication.

The final decision involves routing, which delineates the navigation from one view to another [8]. Usually, hyperlinks are necessary to navigate between screens. When adopting CSC, the application shell manages routing, which knows all routes and MFEs, mapping URLs to the correct MFE.

The Table I summarizes our quantitative results, which we ranked according to the harmful score values. Column 1 presents the titles of the anti-patterns evaluated in the survey. Columns 2 and 3 report the participants’ agreement rates regarding the clarity of the problem presentation and the proposed solutions of the anti-patterns. Column 4 presents the participants’ agreement rates regarding the effectiveness of the proposed solutions for the problems identified in the anti-patterns. Column 5 shows the percentage of participants who have encountered the problems described in the anti-patterns in their practitioner experience within the software industry. Column 6 presents the median values of harmfulness attributed to the anti-patterns by the participants.

Regarding the clarity of the problems and solutions presented in the anti-patterns, the results show that the participants had a thorough understanding, as demonstrated by the high values in Columns 2 and 3, which range from 95% up to 100%. Moreover, the high values presented in Column 3 indicate a positive efficacy of the solutions, on which a large majority of participants recognized the proposed solutions as effective means of addressing the issues posed by the anti-patterns.

The values in column 5 indicate that practitioners frequently encounter the anti-patterns Cyclic Dependency, Knot Frontend, Hub-like Dependency, Mega Frontend, and No CI/CD in software projects. Notably, seven of the remaining eight anti-patterns were reported by more than 50% of participants, highlighting their common occurrence as well. The only anti-pattern observed by less than 50% of participants is the Nano Frontend, in contrast to the Mega Frontend. This suggests that practitioners are more likely to create larger MFEs than smaller ones.

Given the limited sample size, we assessed the reliability of the harmfulness scores using several statistical tests. First, we applied the Shapiro-Wilk Test with a 95% confidence level to determine if the samples were normally distributed. The test indicated that only half of the anti-patterns (namely Cyclic Dependency, Knot Micro Frontend, Nano Frontend, Mega Frontend and Golden Hammer) follow a normal distribution.

We then used the Friedman test to evaluate whether there were statistically significant differences in the harmfulness scores. The Friedman test yielded a $p-value$ of $0.0000001581$ $(<0.05)$, which strongly suggests that there are statistically significant differences in harmfulness scores among the anti-patterns. Subsequently, the post-hoc Dunn test revealed that only two anti-patterns exhibited statistically significant differences compared to others: Golden Hammer differed from Hub-like Dependency, No CI/CD, Lack of Skeleton and Common Ownership; and Micro Frontend as the Goal differed from Hub-like Dependency. The implementation of the statistical tests and their results are available in our supplementary material⁸⁸8https://github.com/nabsonp/ICSE-2025/blob/main/Statistic_tests.ipynb.

While Dunn’s test did not indicate significant differences between most pairs, the boxplot visualization (Figure 2) reveals notable trends. No CI/CD is perceived as significantly more harmful than other anti-patterns, as evidenced by its higher median score. Conversely, Golden Hammer is considered the least harmful, with the lowest median harmfulness score (6). These findings suggest that while statistical significance was not universally achieved, there is a strong perception that the absence of CI/CD is particularly harmful, whereas the reuse of familiar technologies is seen as acceptable.

Based on the open coding quotations, the first author defined eight themes (Figure 3). Subsequently, the second author independently categorized the same quotations using the established themes. On measuring the ICR, we obtained a Cohen’s Kappa with a value of 0.84. According to Landis and Koch [32], this is considered an almost perfect score, highlighting the reliability of our coding process and the robustness of the identified themes. In the following paragraphs, we present a brief explanation of each category and its main findings. The full thematic analysis is available in our supplementary material⁹⁹9https://github.com/nabsonp/ICSE-2025/blob/main/Thematic_Analysis.pdf.

Commendations to the catalog – compliments to the catalog: P2 acknowledged the novelty of the anti-patterns due to the lack of ones that focus on the MFE development, as stated in “The term and technology is fairly new, and such patterns are not well established in the software community yet.” P5 praised the catalog for addressing practical issues that practitioners face when working with MFE, as commented in “This catalog highlights several real-world problems encountered in the day-to-day work with micro frontends.”

How to use the catalog – how the catalog can be used to improve the development and maintenance of MFE architectures: P2 highlighted that the catalog may provide essential guidance for best practices and avoidables in MFE development, as stated in “It will serve as a guide for some ‘Dos’ and ‘Donts’ that are missing in the Micro Frontends world.” P7 commented on the practical utility of the catalog in educating and integrating new team members in MFE software projects, as stated in “Training new team members and onboarding them to micro frontend projects.” P9 observed that the catalog may help in whether to use or not MFE architecture in “think about architecture decisions and the decision to use micro frontends architecture or not.”

Improvements to examples – proposals for new examples or enhancements to the presented ones: For Cyclic Dependency, P4 suggests that the example should include all necessary dependencies to fully close the cycle, as noted, “The example only states a dependency between A and B, but not another that would close the cycle between B and A.” For Hub-like Dependency, P4 provided a practical scenario that emphasizes the importance of robust error handling in “A main banking screen that has charts, lists, and balances. If this screen implements its own data fetch function that fails and renders the screen useless, then it is a problem.”

Improvements to problem definition – enhancements to anti-patterns problems definitions: P8 suggested the need for a clearer definition in Micro Frontends Greedy, once they had difficulty in distinguishing it from the Nano frontend or Mega frontends anti-patterns, as stated in “I can’t separate this anti-pattern from nano or mega frontends.” For Common Ownership, P15 pointed out that small teams can also benefit from characteristics inherent of software modularization, as mentioned in “Naturally, larger software involves more people, but I believe small teams can also benefit from software modularization, such as separation of layers and responsibilities, observability and maintainability.”

Improvements to solutions – enhancements to anti-patterns solutions: P2 suggested that the Knot Micro frontend anti-pattern should clearly define the difference between a good communication pattern and a bad one, as stated in “Solution could state what is a good communication pattern vs a bad one.” For Hub-like Dependency, many participants suggested that the solution of avoiding aggregator screens does not address the problem correctly because, in the context of MFE architecture, screens will include many MFE fragments, as P2 emphasized in “It is inevitable to have aggregators,” and P20 in “But not use it goes against the main idea of the MFE to be contextually segregated.” P5 emphasized that the solution for Nano Frontend will rely on the organizational context it is inserted in, as stated, “The solution here will depend entirely on the organizational context.”

Improvements to the catalog – enhancements to the catalog as a whole: Most of the participants focused their suggestions for improving the catalog adding visual aids for enhancing the readability of the catalog, as P4 suggests in “I would use some flow charts to exemplify most of the anti-patterns and make it more readable,” and P18 complements in “Add some diagrams and images help to understand some examples.”

New anti-patterns – proposals of new anti-patterns: P2 discussed the importance of choosing between build-time and runtime integration based on team and user needs, as stated in “There are mainly two ways to integrate micro frontends: build-time and runtime. The decision on which to adhere reflects deeply in the teams’ and users’ needs more than the technical pros and cons each of them offer.” P7 highlighted that data persistence on MFEs may become an anti–-pattern due to the issue when different MFE manage the state, as commented, “Poor state management: Data persistence on MFEs when each frontend manages the state independently.” Lastly, P8 suggests that Inconsistent User Experience is an existing issue in MFE.

Proposal of new solutions – proposals of different solutions for specific anti-patterns: For Mega Frontend, P4 suggested that better discussions between the product team and the development team could help define when features should be treated as different products, as stated in “Lack of communication between the product team and the development team. It should be well discussed between the two teams to define when two or more features are different products.” For Golden Hammer, P7 proposed adopting hybrid technology approaches for solving the problem, as commented in “Adopting a hybrid technology approach supported by a common facade, such as a Backend for Frontend (BFF) layer, and using feature flags to manage gradual migration and experimentation might be a better approach.”

Category: Inter-frontends

Problem: Two or more MFEs directly or indirectly depend on each other, resulting in high coupling between screens and fragments, compromising MFEs’ independence and modularity. Thus, changes in one MFE require coordination with the others. Circular dependencies lead to challenges in a system’s maintenance and evolution, compromising agility and the ability to scale developments efficiently.

Solution: High coupling between MFEs can be effectively mitigated through event-based communication, which removes the need for direct dependencies between MFEs. Instead, interactions are handled indirectly via a centralized event store. On implementing the Publish-Subscribe (Pub-Sub) pattern, an MFE can publish an event to the browser, allowing other MFEs to subscribe and respond when the event occurs. To ensure consistency and reduce errors, it is recommended to centralize event definitions in a shared library.

Category: Inter-frontends

Problem: A Knot is composed of three or more MFEs whose communication with each other uses a context-specific interface. This means that navigation and data exchange between screens and fragments heavily depend on the unique context of each MFE involved. Adding new MFEs exacerbates the problem: as the number of MFEs grows, the interface complexity increases due to the introduction of new contexts, creating a highly coupled Knot that becomes difficult to maintain and integrate new functionalities.

Solution: A practical solution to address the problem of Knots is to implement domain-driven communication interfaces that are both generic and flexible. These interfaces should define a contract based on the domain model, specifying the essential fields required for each MFE to function correctly and interact with others. On designing new fields or attributes, it is essential to ensure their consistency and reusability and minimize tight coupling so other MFEs can utilize them. We recommend including a generic field in the interface containing a list of objects with standard properties such as label, value, and type, allowing each MFE to display data on the screen without needing to understand the specific meaning or context of the values. This approach reduces coupling between MFEs, while maintaining benefits such as modularity, scalability, and adaptability to new requirements.

Category: Inter-frontends

Problem: A screen of an MFE integrates fragments from several other MFEs, becoming a central point of interdependence. Any issue occurring in the main screen or one of its fragments can affect all other fragments present on it.

Solution: To prevent a single fragment failure from crashing the entire main screen, the screen should be kept as simple as possible, and each fragment should implement robust error-handling mechanisms. This can be achieved by implementing a strategy where uncaught errors within a fragment gracefully degrade its functionality, displaying a user-friendly fallback message. This approach ensures that users are informed of the issue without hindering their interaction with the remaining functionalities on the main screen.

Category: Intra-frontends

Problem: The frontend decomposes into numerous small MFEs with few screens or fragments. Small MFEs do not justify the cost of their maintenance. Furthermore, the presence of nano frontends can lead to issues of high coupling and the manifestation of other anti-patterns, such as cyclic dependency.

Solution: The issue of nano frontends arises when the definition of boundaries is inadequately and excessively granular. Adhering to Domain-driven Design [33] principles is necessary to ensure an effective decomposition of MFEs. Therefore, the development team must work closely with the product team to gain a deep understanding of the domains and reflect them accurately in the architecture. To solve this issue, the architecture must be redesigned by grouping MFEs with the same domain is necessary. For minor variations within a domain, consider using templates or component libraries. This approach avoids creating a separate MFE for each slight variation, promoting efficiency and code reuse.

Category: Intra-frontends

Problem: Decomposing the architecture into a few MFEs encompassing numerous screens and fragments manifests this anti-pattern. The MFE inherits the challenges of a monolithic frontend, such as difficulties in testing, slow builds and deployments, high coupling between its components, lack of modularity, and limited scalability.

Solution: To avoid this problem, the development team must work closely with the product team to gain a deep understanding of the domains and reflect them accurately in the architecture. To fix this issue, the team should reevaluate the architecture and divide the MFEs into more granular units, separating functionalities into smaller and specialized MFEs based on domains. This approach helps reduce complexity, enhance maintainability, and foster a modular and scalable architecture.

Category: Intra-frontends

Problem: When a developer is uncertain about creating a new MFE, the common practice is to opt for its creation. Whenever a need arises to develop a new set of screens or fragments, a new MFE is instantiated. This can lead to an explosion in the number of MFEs, making the system difficult to understand and increasing the likelihood of both nano and mega frontends emerging.

Solution: To determine where to implement a new feature composed of a set of screens and/or fragments, the domain of the new feature must first be defined. If it falls within the domain of an existing MFE, it should be implemented there. In this case, a summary of all MFEs, their contexts, and domains can help identify the best fit for the new feature. If it belongs to a brand new domain, one or more MFEs should be defined based on the domain definition. Establishing well-defined domains relies on collaboration between the development and product teams to define boundaries accurately.

Category: Operations

Problem: The company lacks an automated Continuous Integration (CI) and Continuous Delivery (CD) pipeline, so developers must manually execute tests and perform deployments. This manual process becomes burdensome, especially with the potential existence of multiple MFEs. It increases development time, reduces productivity, and raises the risk of errors in the production environment.

Solution: Implement an automated and replicable CI/CD process that extends for new MFEs, ensuring they will have automated test execution and deployment consistently and efficiently. This should be part of the Definition of Done (DoD) of the architecture.

Category: Operations

Problem: The MFEs are not versioned. Small and large changes can impact the integration between different MFEs and cause errors. Consequently, the MFEs become less independent, requiring coordinated deployments.

Solution: Adopting a versioning approach like Semantic Versioning is essential to ensure that changes do not impact functioning versions. For example, consider a fragment that is used in screens across different MFEs in a client-side rendering scenario. Without versioning, any change to the fragment’s parameters or return values could break the interaction on all the screens it integrates with. However, with versioning, such updates would not impact the current versions used by other MFEs, as they can continue to request the previous version of the fragment and update at their convenience. This approach helps maintain a stable environment and minimizes disruptions caused by updates.

Category: Operations

Problem: No skeleton or predefined boilerplate is available as a base for creating new MFEs. This leads to the creation of MFEs from scratch or based on an existing MFE and inheriting its issues. The consequences include wasted time, increased risk of errors, duplicated code across MFEs, and a need for more standardization in development.

Solution: Whenever a new technology is used to implement an MFE, the development team must create a repository containing the necessary base code, known as a boilerplate. The boilerplate should enable the creation of new MFEs with the same technology by simply cloning it. Keeping the boilerplate updated with new design patterns and library versions is crucial. Additionally, the development team should create comprehensive documentation detailing the entire process of creating a new MFE, regardless of the technology. This documentation should provide instructions on adding automated CI/CD, integrating the MFE into the existing system, and addressing other relevant aspects.

Category: Development

Problem: A single team is tasked with managing all MFEs, which can occur either due to a lack of team division or when teams are segmented based on technical aspects such as data, frontend, and backend. However, one of the key benefits of MFE architecture is independence, so adopting MFE Architecture without distinct teams to operate independently negates this advantage.

Solution: Context should be the defining factor when structuring development teams. Therefore, defining the boundaries of teams and MFEs is essential according to Domain-driven Design [33], so a team will be responsible only for MFEs within its domain. Creating shared libraries can facilitate boundary definition and promote greater team independence.

Category: Development

Problem: All MFEs utilize the same technology, even if it does not meet the specific needs of each MFE. It happens due to developers’ familiarity with only one specific technology. This approach limits the architecture, failing to take advantage of the benefits of the possibility of a heterogeneous architecture, which is one of the main attractions of adopting MFEs.

Solution: To choose the most suitable technology that addresses the specific challenges of each MFE, which includes adopting the correct programming languages, frameworks, and libraries during its development. When uncertain about a particular technology, conducting a proof-of-concept (POC) can validate its suitability. Testing new technologies through POCs helps validate their suitability without compromising the establishment of standardized patterns within the company. However, it’s important to note that increasing the variety of technologies can increase the complexity of the architecture.

Category: Development

Problem: Adopting the MFE architecture in inappropriate contexts can lead to more issues than benefits, especially in systems with few screens and low complexity or in companies lacking a sufficient number of developers to create dedicated teams for different application domains. In such situations, the maintenance costs of the architecture may outweigh the expected benefits, making its implementation unfeasible.

Solution: Software teams must consider carefully different aspects of adopting MFE architecture. Considering the system’s complexity, the feasibility of maintaining automated CI/CD pipelines and the team’s restructuring according to different domains is necessary.