Micro Frontend-Based Development: Concepts, Motivations,

Implementation Principles, and an Experience Report

Fernando Rodrigues de Moraes

1,2 a

, Gabriel Nagassaki Campos

Nathalia Rodrigues de Almeida

and Frank Jos

e Affonso

1 b

Department of Statistics, Applied Mathematics and Computation, S

ao Paulo State University – UNESP,

PO Box 178, Rio Claro, S

ao Paulo, 13506-900, Brazil

VR Software, 59 Narciso Gonc¸alves Street, Jardim Cidade Universit

aria, Limeira, S

ao Paulo, 13484-646, Brazil

Keywords:

Micro Frontend Architecture, Development Approaches, Web Development.

Abstract:

Micro frontend is an architectural style that enables us to build large software systems by combining inde-

pendent micro applications, which can boost different aspects related to the development (e.g., innovation,

continuous software delivery), besides increasing the ﬂexibility and scalability of the ﬁnal application itself.

Although there are numerous beneﬁts related to this architectural style, some companies are still hesitant to

adopt development based on micro frontends because of a lack of knowledge about concepts, development ap-

proaches, architectural models, and organizational aspects of the company. This paper presents the results of a

Systematic Mapping Study (SMS) on micro frontends based on 16 studies. The results were synthesized in an

important overview that addressed concepts, aspects related to development (i.e., development approaches, ar-

chitectural models, and company organization), and micro frontend trade-offs based on three scenarios. Next,

we present a case study on an inventory control application based on the knowledge of this SMS, analyzing the

development under three approaches (i.e., Build-time, Frameworkless, and Framework-based). As result, we

observed our paper has a good perspective to contribute efﬁciently to the micro frontend domain by providing

an overview of this research area and an experience report for researchers and practitioners.

1 INTRODUCTION

Designing the presentation layer of a contemporary

Web application is a vital task for software develop-

ment companies. Development teams have shown in-

terest in exploring innovative approaches to create,

deploy, and maintain applications efﬁciently, enabling

companies to swiftly and effectively provide value to

their customers. In this direction, micro frontends are

increasing in popularity in small and large companies,

because this technology enables to split off a mono-

lithic frontend into independent and micro applica-

tions, developing the same frontend application by

different teams (Bian et al., 2022; Mena et al., 2019;

Mannisto et al., 2023; Peltonen et al., 2021).

Regarding development, the main purpose of mi-

cro frontends is to organize an application (i.e., Web-

site or Web app) as a composition of features that

are owned by independent teams, developing its fea-

https://orcid.org/0009-0004-8631-9385

https://orcid.org/0000-0002-5784-6248

tures like a full-stack specialist (i.e., from database

to user interface) (Shakil and Zoitl, 2020). In paral-

lel, microservice is an architectural style used to build

distributed applications organized in a collection of

services around business capabilities and indepen-

dently deployable by automated deployment (Lewis

and Fowler, 2014). Analyzing these two technologies,

it can be said that micro frontend extends microser-

vice because employs similar concepts. In short, we

can segment a Web application into individual mod-

ules in a Micro Frontend Architecture (MFA), and

implement them independently. The combination of

these two technologies enables frontend teams a level

of ﬂexibility and quickness analogous to the bene-

ﬁts that microservices offer to backend teams (Mo-

hammed et al., 2022; Lewis and Fowler, 2014; Geers,

2020; Jackson, 2019).

Although there is a relationship between the afore-

mentioned technologies (microservice and MFA), we

observed that MFA is still at a premature stage of

development and requires deeper and more solid in-

vestigation. Despite the notorious volume of docu-

Moraes, F., Campos, G., Almeida, N. and Affonso, F.

Micro Frontend-Based Development: Concepts, Motivations, Implementation Principles, and an Experience Report.

DOI: 10.5220/0012627300003690

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 26th International Conference on Enterprise Information Systems (ICEIS 2024) - Volume 2, pages 175-184

ISBN: 978-989-758-692-7; ISSN: 2184-4992

175

mentation available on the Web, this information still

does not come from reliable sources, making compa-

nies not feel comfortable using it. This distrust comes

from the lack of establishment of concepts, applica-

tion scenarios, and a clear exposition of beneﬁts that

can be achieved. Furthermore, there is a certain con-

tradiction between the concepts, deﬁnitions, and ar-

chitectural models found in these sources of informa-

tion. Thus, as happened with microservices, teams

that were unprepared from a conceptual and techno-

logical point of view had severe difﬁculties in adopt-

ing the MFA (Soldani et al., 2018).

This paper presents a study on software develop-

ment based on micro frontends, whose research in-

terest was the formulation of concepts, integration

approaches, management aspects (organizational and

development), application scenarios, and micro fron-

tend trade-offs. To establish a fair and broad overview

of the aforementioned interests, we have adopted the

Systematic Mapping Study (SMS) process proposed

by Kitchenham and Charters (2007); Petersen et al.

(2015). Next, based on the established panorama, we

conducted a case study for a inventory control system,

where the following aspects were explored: the or-

ganization of the system concerning the architectural

model; the company’s structural organization about

the adoption of micro frontend architectural style; the

development team’s management; and the experience

report through a case study developed based on three

approaches. Thus, we identify the following contribu-

tions for our paper: (i) a solid panorama of the related

to the development based on micro frontend; (ii) the

main aspects of the management when designing mi-

cro frontend application(s) (MFApp(s)); (iii) the case

study as an experience report for the micro frontend

development based on the integration approaches; and

(iv) the micro frontend trade-offs.

The remainder of this paper is organized as fol-

lows. Section 2 introduces the main concepts related

to development based on micro frontends and related

work. The main ﬁndings of our SMS is reported in

Section 3. Section 4 shows the key aspects of mi-

cro frontend development based on the integration ap-

proaches. Section 5 provides a discussion of results

on the main ﬁnding. Finally, Section 6 summarizes

our conclusions and perspectives for further research.

2 BACKGROUND AND RELATED

WORK

In this section, we present the background that con-

tributed to the development of our paper. Initially,

concepts of microservices, micro frontends, and three

development approaches for micro frontends are pre-

sented. Next, related work on software development

based on micro frontends is addressed.

Microservices and Micro Frontends. According

to Lewis and Fowler (2014), the microservice archi-

tectural style is an approach to developing a single

application based on a suite of small services, each

one running in its process and communicating with

lightweight mechanisms. These services are built

around business capabilities and can be independently

deployable by fully automated deployment. These

features enable teams to be organized around an appli-

cation, besides boosting continuous software delivery.

In parallel, Jackson (2019) deﬁned micro frontends as

“an architectural style where independently deliver-

able frontend applications are composed into a greater

whole”. According to this last author, the main ben-

eﬁts of micro frontends can be summarized in three

features: (i) more cohesive and maintainable code-

bases; (ii) scalable organizations with decoupled and

autonomous teams; and (iii) incremental development

with continuous delivery of software. As observed,

these features represent some of the same advantages

that microservices can provide (Peltonen et al., 2021).

Development Approaches. The development of

applications based on MFA can be conducted

through three integration approaches (Jackson, 2019),

namely: (i) Build-time; (ii) Frameworkless; and

(iii) Framework-based. Before presenting these ap-

proaches, two considerations must be highlighted.

First, in Frameworkless and Framework-based ap-

proaches, the term framework is used or referenced

as an architectural framework for supporting the de-

velopment of software based on micro frontends and

not as a framework for Web development. Second, the

Build-time approach differs from the others because it

does not enable integration at runtime, meaning that

micro frontends are packaged and coupled to the main

application at compile time. Next, we addressed a de-

scription of each approach.

Build-time is the simplest approach to the architec-

tural implementation of micro frontends because it

enables the development of micro applications as

packages. This approach does not depend on a frame-

work or particular implementation because it imports

libraries in a container application, which is respon-

sible for calling each MFA. Although simply, this

approach does not meet the main principles when

compared to microservices features such as language

agnosticism, fault isolation, and independent deliv-

ery of micro frontends container (Stefanovska and

Trajkovik, 2022; Pavlenko et al., 2020; Lewis and

Fowler, 2014; Jackson, 2019).

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

176

Frameworkless is a type of approach that does not

require frameworks for software development. Ac-

cording to (Frameworkless, 2023), the lack of knowl-

edge that developers have when adopting a frame-

work and the technical debt that this can generate in

a project has been one reason for adopting this ap-

proach type. Since MFA is technology agnostic, Man-

nisto et al. (2023) reported an experience based on a

Frameworkless approach as a feasible alternative for

small organizations, providing improvements in the

development and deployment of MFAs. In this direc-

tion, we can highlight some elements that can sup-

port this approach, namely: (i) Webpack, a Web ap-

plication packaging tool that can handle Javascript,

HTML (HyperText Markup Language), CSS (Cas-

cading Style Sheet), and images; (ii) Module Feder-

ation, a tool that enables the use of exposed exter-

nal modules, allowing the applications’ remote code

to be consumed to build an integrated application at

runtime; (iii) iFrame, an HTML element that enables

the integration of other HTML elements (e.g., sin-

gle pages, micro frontends); (iv) Web components,

a technology used to create and reuse different Web

components with functionality decoupled from the

code; and (vi) Signal-based Web Components (Ste-

fanovska and Trajkovik, 2022; Nishizu and Kamina,

2022; Pavlenko et al., 2020), a technology that uses

reactive programming paradigm to facilitate the fron-

tend construction with better code organization.

A Framework-based approach enables a prag-

matic and successful implementation according to

guidelines established within an architectural frame-

work used to implement integration between MFAs,

avoiding high effort demands (e.g., time) being used

to design the ﬁnal product, still providing built-in

mechanisms to overcome anti-patterns solutions, and

exposing APIs and plugins to help teams to achieve a

highly maintainable micro frontend solution.

Drawing a parallel between the approaches pre-

sented in this section, the ﬁrst two demands that

teams implement their code to sustain an MFA, and

the last one follows the conventions and restrictions

of the frameworks. Although the multi-framework

approach has been discouraged (Geers, 2020), we

found architectural frameworks that enable the in-

tegration of MFAs built in different Web develop-

ment frameworks (e.g., React

), without high efforts

with API design and micro frontend implementation,

namely: (i) single-spa (Single-spa, 2016); (ii) qiankun

(Qiankun, 2019); and (iii) Garﬁsh (Garﬁsh, 2021).

As related work, to the best of our knowledge,

there is no paper about software development based

on micro frontends that approaches the interests of in-

https://react.dev

vestigation reported in Section 3. To ensure the orig-

inality of our paper, we conducted a literature inves-

tigation to establish a solid and complete deﬁnition

of micro frontends, besides aspects related to the de-

velopment and real needs to adopt this architectural

style by the companies. The evidence revealed that

the studies available in the literature addressed differ-

ent aspects of the investigation, leaving gaps related

to the micro frontend architectural style itself and as-

pects associated with software development.

3 MICRO FRONTENDS

As reported in Section 1, we have adopted the SMS

technique to establish a fair and broad overview

of software development based on micro frontends.

To do so, we elaborated a research protocol based

on guidelines proposed by Kitchenham and Charters

(2007) and Petersen et al. (2015) that will not be pre-

sented in this paper for space reasons. Details of this

protocol and the ﬁnal list of selected studies are pre-

sented in full in Moraes et al. (2023). Next, we report

the main ﬁndings of our investigation in Sections 3.1–

3.3, which can be considered for the software design

based on micro frontends.

3.1 What Is Micro Frontend?

An MFA is a microservices-inspired architectural

style that implements an application as a collection

of frontend applications decoupled that must be mod-

eled around a business domain, enabling the building

of micro applications as smaller, loosely coupled, and

independently deployable components. In an MFA,

each user interface (UI) portion can be treated as com-

ponents or pages and can become a new MFApp,

which is developed, tested, deployed independently,

and containerized in a unique UI. In parallel, one can

say that this modular organization enables the adop-

tion of small autonomous teams with different tech-

nological expertise (i.e., own technology stacks and

deployment pipelines), reduces the dependency be-

tween development teams, boosts the governance of

such teams, reduces business complexity, has the po-

tential to encourage innovation, and can optimize the

maintenance activity of these applications in the fu-

ture (Tilak et al., 2020; Noppadol and Limpiyakorn,

2021; B

uhler et al., 2022; Pavlenko et al., 2020; Taibi

and Mezzalira, 2022; Yang et al., 2019).

Besides the established deﬁnition, our research

suggests to the stakeholders that the design of an ap-

plication based on micro frontend must be guided by

knowledge and decisions illustrated in Figure 1. In

Micro Frontend-Based Development: Concepts, Motivations, Implementation Principles, and an Experience Report

177

(A), we show the organization of an MFApp in three

layers (i.e., frontend, backend, and database), where

each column represents a development team working

in full-stack mode (Oliveira et al., 2022; Yang et al.,

2019). Next, we present possible layout decisions in

(B), where the developers must deﬁne how the mi-

cro frontends will be organized. To do so, the devel-

opers can choose two layouts: (i) horizontal, which

enables multiple micro frontends per page; and verti-

cal, which enables one micro frontend per page. Re-

garding composition (C), an MFApp can be designed

in three ways, namely: client-side, edge-side, and

server-side. In the ﬁrst, an application retrieves sev-

eral micro frontends from a Content Delivery Net-

work (CDN), typically using JavaScript or an HTML

ﬁle as the entry point for each micro frontend. The

second builds the view at the CDN level by fetching

your micro frontends from the origin and then deliver-

ing the outcome to the client. The micro frontends are

composed within a view in the third way, where they

are cached at the CDN level and ultimately served

to the client either at runtime or during compile time

(Taibi and Mezzalira, 2022).

Finally, after deﬁning the composition of the mi-

cro frontends, it is important to deﬁne two additional

elements: routing and communication. Routing delin-

eates the route from one view to another, dictating the

traversal process. The communication outlines how

micro frontends interact with each other, once data

sharing is indispensable for both horizontal and verti-

cal divisions (Pavlenko et al., 2020). Section 3.2 dis-

cusses routing and communication, as these aspects

directly rely on the chosen approach and implementa-

tion strategies for this architectural style.

3.2 How Should the Development of

MFApps Be Managed?

Before we introduce any appoint to this question, it

is important to highlight some aspects related to de-

velopment based on micro frontends, since the focus

here is large-scope and distributed Web/Mobile ap-

plications. In this direction, aligning concepts and

best practices between microservices and micro fron-

tend reported in Section 2 enables us to establish a

modular organization of development teams around

the application’s business capabilities. In short, such

capabilities are smaller, speciﬁc features that can

boost application scalability, optimize the reuse of

features/components, and facilitate the reduction of

development complexity. Moreover, the ﬁndings of

our SMS have revealed some evidence regarding the

management of software development based on mi-

cro frontends. As MFA is an architectural style that

comes from industrial environments, we can also

mention the following beneﬁts related to the decou-

pled development process, namely: (i) governance,

which enables us to organize teams in autonomous

vertical teams with capabilities in incremental up-

dates; and (ii) agile behavior, which allows us to de-

velop applications part of the MFA without causing

negative impacts on other parts of the software, while

optimizing the delivery process of a software product.

Based on the content exposed in this section and

the evidence identiﬁed in our mapping studies, it is

suggested the management of applications based on

micro frontends can be guided based on two essen-

tial elements: company organization and architecture.

Next, we addressed a description of each element.

Company Organization. As emphasized by Jackson

(2019), it is essential to establish an organizational

approach within the Software Development Life Cy-

cle (SDLC) to achieve success with MFA. The main

purpose of an organizational approach is to soften

operational complexity through speciﬁc measures re-

lated to the following items: (i) automation, the de-

velopment of decoupled applications requires auto-

mated processes to reduce complexity concerning the

team setup. In parallel, such processes must also sup-

port the deployment of these micro applications, since

the proposed architecture (MFA) increases infrastruc-

ture complexity in both: development and deploy-

ment (Taibi and Mezzalira, 2022); (ii) process, a mi-

cro frontend team must deal with the development,

testing, and release of applications in short cycles of

continuous delivery of software using a pipeline or-

ganized into a “production-like environment”. To do

so, the software engineers must plan and organize an

SDLC process to scale the teams concerning an ar-

chitecture (Pavlenko et al., 2020; Taibi and Mezza-

lira, 2022); (iii) practices, an MFA requires decen-

tralized processes and tools so that an organization

(i.e. development teams) feels comfortable adjust-

ing itself as an autonomous vertical team (Jackson,

2019); and (iv) quality, decentralized codebases and

teams can represent a challenge for an organization

that intends to maintain software quality. In general,

it is harder to keep quality in multiple and decentral-

ized processes in SDLC, even considering that micro

applications and smaller teams cause less impact in a

software ecosystem than in a monolith system.

Regarding operational complexity, we can deﬁne

organizational processes to reduce possible problems

and increase architectural reliability. In this direction,

pipelines to deliver and integrate software can be a

feasible alternative to overcome such complexity be-

cause they automate all the integration processes and

software deployment to the codebases of each appli-

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

178

MFA 1

(Team A)

Footer

Header

MFA 2

(Team B)

Team A:

DC1

Footer

Header

Team A:

DC2

Team B: DC1

Footer

Header

Team B: DC2

Team A (MFA 1) Team B (MFA 2)

Horiontal split

Vertical split

Micro Frontend

Aplication

Mission A

Mission C

Mission B

Frontend

Backend

Database

MFA1 MFA2 MFA3

Web Pages

MFA1 MFA2 MFA3

Client-side Edge-side Server-side

Origin

(Server)

CDN

Client

(WP)

(A) Micro frontend (C) Composing

(B) Split

Legend MFA:DC:CDN: Web PagesContent Delivery Network Domain Components Micro Frontend Aplication WP:

Team A Team B Team C

Figure 1: Deﬁnitions and decisions about MFApps.

cation (Taibi and Mezzalira, 2022). Furthermore, mi-

cro frontend-based development can be deﬁned as the

ideal scenario for setting up vertical teams that own

different small frontend applications. This organiza-

tional model provides these teams greater freedom to

develop tools and processes, alleviating architectural

complexity and addressing concerns regarding decen-

tralized development practices and team quality stan-

dards. Finally, it is recommended that the division

of micro frontends be carried out around the business

domain to keep each micro frontend in its specialized

domain, besides ensuring its decoupling, increasing

the quality level, and decentralized practices.

As observed in this section (Architecture Ele-

ment), the adoption of micro frontend as an architec-

tural style can be facilitated by considering trade-offs.

The pros and cons analysis of any software project

must be mindful of the inherent aspects of any ar-

chitectural style. Therefore, based on the MFA pre-

sented in this paper (see Figure 1), it can be said in-

dustrial cases denote that a well-executed implemen-

tation of micro frontends, with clearly deﬁned pro-

cesses, contributes to a more efﬁcient organizational

scale in frontend applications (Yang et al., 2019).

Architecture. As we deﬁne the company’s organiza-

tional structure, it is mandatory to establish a develop-

ment approach. Choosing from different architectural

implementations, including the innovative concept of

micro frontends, enables us to make this decision by

considering the features of each approach. The matu-

rity evaluation of the development team and parame-

ters related to the project’s scalability must also guide

this decision.

As reported in Section 2, the main choice that has

to be deﬁned in an MFA is an integration approach

(see Development approaches item), namely: Build-

time (BT), Frameworkless (FL), and Framework-

based (FB). In this architecture type exists an entry-

point application, which can be called an application

container so that it can render the initial elements. In

short, these elements are used by the user’s applica-

tion to access other pages and elements that can be

different micro frontends. Based on the distinct trade-

offs associated with each approach, we recommend

that each development team conduct a self-analysis

to determine the most optimal choice for each project

and the organizational context of each company. Ta-

ble 1 provides a tabular representation of the main fea-

tures identiﬁed in the BT, FL, and FB approaches.

Table 1: Comparison of development approaches.

Features BT FL FB

Modeled around domain ✓ ✓ ✓

Decentralized governance ✓ ✓ ✓

Automation culture ✓ ✓ ✓

Incremental upgrades ✓ ✓ ✓

Independent deploy ✓ ✓

Failure isolation ✓ ✓

Architectural boundaries ✓

Analyzing the distribution presented in Table 1,

the FB approach has shown full compliance with the

set of features identiﬁed in our investigation (Moraes

et al., 2023). The FL approach failed to address only

one feature, while the Build-time (BT) approach did

not cover three features (Jackson, 2019). As a re-

sult, this analysis can guide a team to make a more

assertive decision about choosing a development ap-

proach, especially for teams that intend to adopt the

use of frameworks (i.e., trade-offs for frameworks) to

support the development of MFApps.

As reported in Section 3.1, an MFA can work as

a component, element, or an entire page. Concern-

ing the organization, the layout is a decision that the

development teams must make before starting the de-

velopment tasks (see Figure 1 – Split area). A micro

frontend as an individual component or element can

Micro Frontend-Based Development: Concepts, Motivations, Implementation Principles, and an Experience Report

179

not be a trivial choice, since it will usually be cou-

pled on a page and will cause increased complexity in

terms of maintainability. Therefore, deﬁning the dis-

tributed impact on the team responsible for a micro

frontend across different pages becomes challenging.

A traditional solution that enables the use of compo-

nents on different pages to share common elements,

components, and even domains in a library can be a

better strategy than using a coupled micro frontend

on multiple pages. Therefore, a (micro) frontend will

share a style guide that makes it visually consistent.

The split strategy is an important decision to cre-

ate composable decoupled micro frontends, as de-

scribed in Section 3.1. Although we have highlighted

two strategies (i.e., horizontal split, and vertical split)

in our deﬁnition, a third called hybrid split can be used

too. In synthesis, the hybrid split enables the combi-

nation of both strategies (i.e., horizontal and vertical

split). In this sense, we can highlight the composition

of a micro frontend via hybrid split due to a micro

frontend that needs a horizontal split on the page.

Regarding the development, Module Federation,

Web Components, and iFrames have been the tech-

nological resources used to create an application con-

tainer that will provide an entry point to render a user

interface and routing strategy to other pages (Wang

et al., 2020; P

oskei and Bub, 2021; Stefanovska

and Trajkovik, 2022). Since MFApps need to com-

municate with each other, data-sharing approaches

must be used in isolated or combined ways, namely

(Nishizu and Kamina, 2022): (i) event-driven uses

the publication and subscription of events to han-

dle state between micro frontends; (ii) signals work

with the emission of signals between micro frontends,

using reactive programming principles (Nishizu and

Kamina, 2022); (iii) global stores are libraries that

use shared and global states for data management;

(iv) query parameters and local storage enable to shar-

ing of small data as query parameters in the micro

frontend URL, as well as transport a larger data load

shared by the browser’s local storage; and (v) con-

text (or technology’s history) stores information about

the stack of previously loaded interfaces, accessed

by the container application and distributed among

different micro frontends. Of the three integration

approaches mentioned in this section (BT, FL, and

FB), framework-based implements some data-sharing

approaches by default, which can be an important

decision-making factor when selecting a framework.

3.3 Do You Need Micro Frontends?

As mentioned in Sections 3.1 and 3.2, the devel-

opment of applications based on the micro frontend

architectural style brings with it a series of impli-

cations. Initially, we identiﬁed in our investigation

that the successful cases (i.e., developing new ap-

plications and/or modernizing the monolith to micro

frontends) expressed having more solid knowledge

about concepts of micro frontends with strong evi-

dence about the pros and cons of this architectural

style (Bian et al., 2022; Wang et al., 2020; P

oskei

and Bub, 2021; Mannisto et al., 2023; Shakil and

Zoitl, 2020). These successful cases also reported

having a solid understanding of the application being

developed and/or modernized and its suitability in the

organization of decision-making teams regarding the

organization of development teams, layout division,

and composition (B

uhler et al., 2022).

Through our mapping process, we identiﬁed a set

of advantages and disadvantages of the use of mi-

cro frontends in different organizations, which differ

in terms of size and development domain. Lessons

learned, beneﬁts, challenges, pros, cons, advantages,

disadvantages, trade-offs, limitations, and pitfalls

were the most recurrent terms found in our mapping

to express the opposing sides of the theme (i.e., micro

frontend). In this sense, we grouped a set of features

concerning the development teams and company or-

ganization that must be taken into consideration when

adopting the micro frontend architectural style.

In the MFA, we can organize the development

teams around the business domain, which must make

local decisions about technology and design choices.

Next, we addressed some beneﬁts arising from this

modular organization: dynamic teams concerning

communication, ease of maintenance (small software

units), fault isolation, incremental adoption, indepen-

dent deployment, modular organization, reusability,

scalability, and technology ﬂexibility. Otherwise, the

modular organization of the development teams can

result in conﬂicting scenarios related to the company

organization and the system, namely:

Scenario 1. Distributed teams are more complicated

to manage, as well as being more complex to

attribute responsibilities and coordinate activi-

ties. In this sense, implementation of cross-

system concerns, communication between teams,

and sharing of data are the most recurring chal-

lenging adversities concerning the company/team

organization.

Scenario 2. The modular organization can be related

to a series of challenges. For instance, organizing

into smaller software units requires special care

in managing dependencies between micro fron-

tends. In parallel, communication between micro

frontends can signiﬁcantly increase the complex-

ity of the application with the routing and orches-

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

180

tration of the micro frontends so that functionality

can be executed. Another aspect inherent to com-

munication, which may be combined with other

factors (e.g., data sharing) is performance over-

head. Sharing data between an application’s mi-

cro frontends may require an excessive number

of message exchanges, which will cause system

overload.

Scenario 3. The development of a decoupled appli-

cation may suffer arising from differences in the

development environment since a micro frontend

operates within a user interface context that in-

herits stylization and shared data (optional). This

bottleneck implies the adoption of processes to

ensure that the micro frontend developed main-

tains visual consistency across the entire frontend.

Although the evidence gathered in this section

does not reveal a silver bullet solution as a tool

for decision-making regarding the need to adopt the

MFA, the issues addressed can serve as an important

reference for the adoption of this architectural style

by concepts presented in Section 3.1, by the sugges-

tions on managing MFApps reported in Section 3.2,

and by the arguments about the real need for this ar-

chitectural style discussed in this section.

4 CASE STUDY: AN

EXPERIENCE REPORT

To evaluate the applicability, strengths, and weak-

nesses of our study, a case study was conducted.

As subject application for our empirical analysis, we

have selected an application addressed to the manage-

ment of product inventory, which will be referenced

from this point onwards as MfaWebApp

. Next, a

brief description of our subject application and the

empirical strategies is presented.

Subject Application. MfaWebApp is a Web applica-

tion that was developed to meet customers who need

to control product inventory. We organized the in-

terface of this application into three pages, one for

each MFA, namely: (i) Dashboard, used to visu-

alize graphs that enable the user to check the prod-

uct inventory input and output data; (ii) Products,

used for registering, listing, changing, and deleting

products that the user intends to control the entry

and exit of inventory in a store; (iii) Inventory,

used to register the entry and exit of products from

the store, the user can view the list of operations,

such as an inventory extract. Figure 2 illustrates

https://github.com/fernandormoraes/mfa-cs

Product

long id

Str ing des crip tio n

double price

St ri ng un it

String sku

Product()

In ve nt or yM ov em en t

long id

double am ount

Dat e mov ement

Mov emen t m Ty pe

Inv ent ory Mo vem ent ()

In v e nt o ry

long id

double am ount

Inv en tor y( )

User

long id

String usern ame

String password

Stri ng emai l

User()

Mo ve m en t

Long id

Str ing des crip tio n

manag er

1 . . *

has

1 . . *

has

Figure 2: MfaWebApp’s UML class diagram.

the complete UML model of our case study. Al-

though our application does not have an extensive

scope of functionality, we consider it a feasible sys-

tem to show the development of MFApps follow-

ing the Build Time, Frameworkless, and Framework-

based approaches (see Sections 2 and 3.2). Draw-

ing a parallel between the model and the MFA afore-

mentioned, the Dashboard MFA deals with the

InventoryMovement class, the Products MFA

deals with the Product class, and the Inventory

MFA deals with the Inventory class.

Empirical Research Strategy. Figure 3 illus-

trates the implementation of the MfaWebApp ap-

plication using the three development approaches:

Build Time, Frameworkless, and Framework-based.

Initially, we conducted technology-agnostic model-

ing of that application (i.e., MfaWebApp) so that

MFApps were identiﬁed (Dashboard, Products,

Inventory). These applications follow the same

organization (i.e., Frontend, Backend, and Database)

as a MFApp illustrated in Figure 1 (Area A).

MFA1

H:P2

MFA2

H:P3

MFA3

H:P4

Framework-based

H:P1

MFA1

H:P2

MFA2

H:P3

MFA3

H:P4

Frameworkless

MAIN

CTR

MFA1

MFA2

MFA3

Bulid-time

MAIN

CTR

H:P1

MAIN

CTR

FAIA

FRONTEND RENDERIZATION

LEGEND

CTR: Container FA: Framework Approach IA: Implementation Approach

H: Host P: Port PM: Package Manager

. . .

</>

. . .

</>

. . .

</>

. . .

</>

. . .

</>

. . .

</>

. . .

</>

. . .

</>

. . .

</>

. . .

</>

. . .

</>

. . .

</>

Figure 3: Organization of the MFApp implementations.

Before starting the description of each ap-

proach, we referenced the MFApps Dashboard,

Products, Inventory as MFA1, MFA2, and

Micro Frontend-Based Development: Concepts, Motivations, Implementation Principles, and an Experience Report

181

MFA3 in Figure 3, respectively. Moreover, MAIN

(i.e., a container application) must be the ﬁrst appli-

cation to be developed for each approach, regardless

of the development approach (i.e., Build-time, Frame-

workless, Framework-based). This application is re-

sponsible for the initial rendering, acting as a commu-

nication bridge between the frontend and the elements

for access to the application’s other micro frontends.

Next, we addressed a description of each approach.

In the Build-time approach, the technology de-

cisions do not represent a major impact on architec-

tural development. In short, the development focuses

on the process of dividing micro applications into dif-

ferent packages/libraries (MFA1, MFA2, and MFA3),

which will be imported into the container applica-

tion (MAIN) so that it can execute the application

entry point. Moreover, It is worth noting that man-

agement of MFApps is carried out by the PACKAGE

MANAGER element (e.g., Maven

). The selection of

dependency management is at the discretion of each

software engineer responsible for the application. Fi-

nally, it is worth highlighting that communication be-

tween the main application and the MFApps occurs

by calling classes and methods exported from the mi-

cro applications. In this sense, it can be said that the

application routing does not change, since the routes

will direct to method calls or exported instances. Fur-

thermore, data sharing between micro applications is

done via parameter passing or global state sharing.

Similar to Build-time, the Frameworkless ap-

proach also does not rely on technologies, since the

development of MFApps is guided by the indepen-

dence of the programming language or framework. In

this sense, we can highlight the following implemen-

tation resources for composing MFApps: (i) iFrames,

which can be included in any technology as an HTML

element; (ii) Web Components, which represents a

set of technologies based on component reuse de-

coupled from code; and (iii) Module Federation, de-

spite being a library developed for Webpack with

JavaScript, Module Federation loads a remote ap-

plication in JavaScript by importing code, so it is

also possible to implement it in any other language.

We used Web Components and Module Federation

in JavaScript micro applications to implement the

MfaWebApp application. Therefore, our implemen-

tation in React had an adaptation in routing, using an

interface for loading remotely hosted Web Compo-

nents. To do so, the interface imports a Web Compo-

nent and uses the browser’s window object, passing

the loaded component via a parameter. We use the

passing of query parameters and the React’s Context

API to share data between micro frontends.

https://maven.apache.org

Finally, the Framework-based approach requires

the selection of frameworks for developing MFApps.

According to our experiences and evidence collected

in the gray literature Micro-frontend.dev (2023), we

suggest ﬁve criteria for selecting frameworks in a soft-

ware project, namely: learning curve, documenta-

tion quality, support quality, quality of the commu-

nity related to the Framework/Library, and level of

adherence concerning development approaches. Al-

though such criteria are easy to interpret, the analy-

ses are subjective to each individual. In this sense,

we recommend adopting some metric that can guide

decision-making. According to Micro-frontend.dev

(2023), the decision matrix can be an alternative to as-

sist any stakeholders in choosing a framework. Based

on the aforementioned criteria, we made the following

choices for the development MfaWebApp based on

the Framework-based approach. A JavaScript frame-

work called Garﬁsh (2021) to manage MFApps was

selected. This framework enables employing the con-

cepts of Module Federation were used to compile mi-

cro applications into a ﬁnal application. The selected

framework (Garﬁsh) manages the decision regarding

routing and data, therefore data-sharing routing im-

plementations are abstracted, enabling greater focus

on the development of micro applications.

5 DISCUSSION OF RESULTS

This section summarizes the main ﬁndings of our pa-

per. As reported in Section 3, our investigation aimed

to establish an important panorama on software devel-

opment based on micro frontend, providing a more

precise and complete deﬁnition of micro frontends

(see Section 3.1), as well as guidelines (i.e., com-

pany and architecture) on the development of this type

of software (see Section 3.2). Finally, Section 3.3,

we described three scenarios that can help any stake-

holder in decisions regarding the choice of this archi-

tectural style. Drawing a counterpoint between our

paper and the study conducted by Nishizu and Kam-

ina (2022), which presented an experience report for

small organizations, our investigation suggests that

the MFA can be applied to any type of software since

the organization features and technological restric-

tions of the development team are met. Undoubtedly,

it is simpler to manage problems/smaller teams; how-

ever, good practices and adequate infrastructure can

boost team productivity, besides enabling continuous

and valuable software delivery.

Concerning the case study reported in Section 4,

the possibilities of technologies and approaches that

can be used are notable since modern frontend de-

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

182

velopment relies heavily on frameworks and libraries.

Furthermore, our case study also addressed opera-

tional complexity, since the entry point for adopt-

ing the MFA involves non-trivial decision-making re-

garding the use of approaches and implementation

techniques. Despite the ease of implementation, the

Build-time approach does not follow all the princi-

ples and advantages that MFA can provide. The

Frameworkless approach can be seen as an attrac-

tion for mature teams in technical terms, since there

are no mature and well-documented frameworks in

the literature, the micro frontend management it-

self can make the architectural implementation more

solid and robust with decisions to the approaches and

technologies. However, the agility seen in modern

software development encourages the use of frame-

works for less complexity, especially when bring-

ing new developers into teams, standardizing devel-

opment processes and quickly delivering software to

the user. Based on this scenario, it can be said that

the Framework-based approach is still at an incipient

stage with little content found in the developer com-

munity, besides the scarcity of documentation.

Drawing a trade-off of the MFA, different ap-

proaches can also present differences in results,

mainly in operational complexity and development

experience. Thus, it can be said that the MFA and

the three approaches presented in this paper should

not be considered as a “silver bullet” solution that can

be used in all development scenarios, leaving the deci-

sion for the development team to best path towards the

project to be developed. This evidence also reveals

the complexity level of this architectural style con-

cerning software development, especially considering

scenarios where there is a predominance of inexpe-

rienced teams and a lack of development infrastruc-

ture since the involuntary application of anti-patterns

in architectures that are not yet mature, can generate

severe negative impacts on software projects.

6 CONCLUSIONS AND FUTURE

WORK

This paper presented an overview of software devel-

opment based on micro frontends, focusing on the

development approaches Build-time, Frameworkless,

and Framework-based. Based on the evidence of our

study, it can be said that micro frontend-based de-

velopment was inspired by the microservice architec-

tural style, borrowing several consolidated concepts

that can be applied to the development of micro ap-

plications such as decentralizing team governance,

maintaining high availability, low coupling, and en-

couraging independent delivery of micro applications.

Next, we report the main contributions of this paper:

(i) a panorama for the development area by establish-

ing concepts, motivations, architectural models, and

principles that can be applied in the development of

MFAs; (ii) a report for the researchers and practi-

tioners by presenting an experience of this architec-

tural style, which can be a reference important for the

new implementations of software systems based on

MFA. In this sense, it is worth highlighting the devel-

opment approaches, company’s organizational struc-

ture, architectural model, and good engineering prac-

tices for companies used in our case study; and (iii) a

case study for the Web development area by exploring

the use of the micro frontend approaches to scalable

Web application projects, permeating Web architec-

ture concepts, and the use of new frameworks for the

proposed architectures (see Figure 3).

As future work, we intend to conduct at least

four activities: (i) conduction a more speciﬁc inves-

tigation about this research theme, considering newer

technologies (e.g., frameworks), architectural styles,

and software architectures; (ii) conduction of a study

related to the decision-making on the architectural

choice of project development using MFA; (iii) con-

duction of more case studies using different frame-

works to evaluate the applicability and feasibility of

the development of micro frontends based on different

frameworks for the industry; and (iv) conduction of

comparative benchmark between micro frontend and

monolith approaches to evaluate the performance and

impact of these architectural models when an appli-

cation is developed. Therefore, based on the content

presented in this paper, a positive research scenario

can be established. Besides the effective contribution

of our paper to the software engineering community,

the industry can beneﬁt from the analysis and experi-

ence reported as a trade-off for the MFA.

ACKNOWLEDGEMENTS

This study was ﬁnanced in part by the Coordenac¸

de Aperfeic¸oamento de Pessoal de N

ıvel Superior -

Brasil (CAPES).

REFERENCES

Bian, Y., Ma, D., Zou, Q., and Yue, W. (2022). A multi-

way access portal website construction scheme. In

The 5th International Conference on Artiﬁcial Intel-

ligence and Big Data, ICAIBD 2022, page 589 – 592.

Institute of Electrical and Electronics Engineers Inc.

Micro Frontend-Based Development: Concepts, Motivations, Implementation Principles, and an Experience Report

183

uhler, F., Barzen, J., Harzenetter, L., Leymann, F., and

Wundrack, P. (2022). Combining the best of two

worlds: Microservices and micro frontends as basis

for a new plugin architecture. Communications in

Computer and Information Science, 1603 CCIS:3 –

23.

Frameworkless (2023). Frameworkless movement. on-line.

https://www.frameworklessmovement.org, acessed on

March 14, 2024.

Garﬁsh (2021). Garﬁsh. on-line. https://www.garﬁshjs.org,

acessed on March 14, 2024.

Geers, M. (2020). Micro frontends in action. Manning Pub-

lications, New York, NY.

Jackson, C. (2019). Micro frontends. on-line. https:

//martinfowler.com/articles/micro-frontends.html,

acessed on March 14, 2024.

Kitchenham, B. and Charters, S. (2007). Guidelines for per-

forming systematic literature reviews in software en-

gineering. Technical Report EBSE 2007-001, Keele

University and Durham University Joint Report.

Lewis, J. and Fowler, M. (2014). Microservices. on-

line. https://martinfowler.com/articles/microservices.

html, acessed on March 14, 2024.

Mannisto, J., Tuovinen, A.-P., and Raatikainen, M. (2023).

Experiences on a frameworkless micro-frontend ar-

chitecture in a small organization. In Proceedings -

IEEE 20th International Conference on Software Ar-

chitecture Companion, ICSA-C 2023, page 61 – 67.

Institute of Electrical and Electronics Engineers Inc.

Mena, M., Corral, A., Iribarne, L., and Criado, J. (2019). A

progressive web application based on microservices

combining geospatial data and the internet of things.

IEEE Access, 7:104577–104590.

Micro-frontend.dev (2023). Micro-frontends and com-

posable frontend architectures. on-line. https://

microfrontend.dev, acessed on March 14, 2024.

Mohammed, S., Fiaidhi, J., Sawyer, D., and Lamouchie, M.

(2022). Developing a graphql soap conversational mi-

cro frontends for the problem oriented medical record

(ql4pomr). In ACM International Conference Pro-

ceeding Series, page 52 – 60. Association for Com-

puting Machinery.

Moraes, F. R., Campos, G. N., de Almeida, N. R., and

Affonso, F. J. (2023). Systematic mapping protocol –

mapping study on. on-line. https://drive.google.com/

ﬁle/d/1CquhVgCo4c5uwBzWeBV2DvBIlM7-KZtn/

view?usp=sharing, accessed on March 14, 2024.

Nishizu, Y. and Kamina, T. (2022). Implementing micro

frontends using signal-based web components. Jour-

nal of Information Processing, 30:505 – 512.

Noppadol, N. and Limpiyakorn, Y. (2021). Application

of micro-frontends to legal search engine web de-

velopment. Lecture Notes in Electrical Engineering,

782:165 – 173.

Oliveira, D. S. M., Oliveira, F. C. M. B., Pernencar, C.

A. C., de Morais, B. S., Silva, J. W., Costa, A. R. B.,

Pereira, J. B. C., and Saboia, I. F. (2022). Licor: Be-

yond the design system. a proposal to empower teams

to develop software in compliance with the principles

of accessibility, usability, and privacy by design in

the extreme contexts and challenging domains post-

covid-19. Communications in Computer and Infor-

mation Science, 1654 CCIS:139 – 147.

Pavlenko, A., Askarbekuly, N., Megha, S., and Mazzara,

M. (2020). Micro-frontends: Application of microser-

vices to web front-ends. Journal of Internet Services

and Information Security, 10(2):49 – 66.

Peltonen, S., Mezzalira, L., and Taibi, D. (2021). Mo-

tivations, beneﬁts, and issues for adopting micro-

frontends: A multivocal literature review. Information

and Software Technology, 136:106571.

Petersen, K., Vakkalanka, S., and Kuzniarz, L. (2015).

Guidelines for conducting systematic mapping stud-

ies in software engineering: An update. Information

and Software Technology, 64:1–18.

oskei, I. and Bub, U. (2021). Enterprise-level migra-

tion to micro frontends in a multi-vendor environment.

Acta Polytechnica Hungarica, 18(8):7 – 25.

Qiankun (2019). Qiankun. on-line. https://qiankun.umijs.

org, acessed on March 14, 2024.

Shakil, M. and Zoitl, A. (2020). Towards a modular archi-

tecture for industrial hmis. In 2020 25th IEEE Inter-

national Conference on Emerging Technologies and

Factory Automation (ETFA), volume 1, pages 1267–

1270.

Single-spa (2016). Single-spa. on-line. https://single-spa.

js.org, acessed on March 14, 2024.

Soldani, J., Tamburri, D. A., and Van Den Heuvel, W.-J.

(2018). The pains and gains of microservices: A sys-

tematic grey literature review. Journal of Systems and

Software, 146:215–232.

Stefanovska, E. and Trajkovik, V. (2022). Evaluating micro

frontend approaches for code reusability. Communi-

cations in Computer and Information Science, 1740

CCIS:93 – 106.

Taibi, D. and Mezzalira, L. (2022). Micro-frontends: Prin-

ciples, implementations, and pitfalls. SIGSOFT Softw.

Eng. Notes, 47(4):25–29.

Tilak, P. Y., Yadav, V., Dharmendra, S. D., and Bolloju,

N. (2020). A platform for enhancing application de-

veloper productivity using microservices and micro-

frontends. In 2020 IEEE-HYDCON, pages 1–4.

Wang, D., Yang, D., Zhou, H., Wang, Y., Hong, D.,

Dong, Q., and Song, S. (2020). A novel applica-

tion of educational management information system

based on micro frontends. Procedia Computer Sci-

ence, 176:1567–1576.

Yang, C., Liu, C., and Su, Z. (2019). Research and appli-

cation of micro frontends. In IOP Conference Series:

Materials Science and Engineering, volume 490. In-

stitute of Physics Publishing.

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

184