Building Micro-Frontends: Scaling Teams and Projects Empowering Developers 1st Edition Luca Mezzalira

Read Anytime Anywhere Easy Ebook Downloads at ebookmeta.com
Building Micro-Frontends: Scaling Teams and
Projects Empowering Developers 1st Edition Luca
Mezzalira
https://ebookmeta.com/product/building-micro-frontends-
scaling-teams-and-projects-empowering-developers-1st-
edition-luca-mezzalira/
OR CLICK HERE
DOWLOAD EBOOK
Visit and Get More Ebook Downloads Instantly at https://ebookmeta.com

Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.
Building Games with Ethereum Smart Contracts: Intermediate
Projects for Solidity Developers Kedar Iyer
https://ebookmeta.com/product/building-games-with-ethereum-smart-
contracts-intermediate-projects-for-solidity-developers-kedar-iyer/
ebookmeta.com
Front-End Reactive Architectures: Explore the Future of
the Front-End using Reactive JavaScript Frameworks and
Libraries 1st Edition Luca Mezzalira
https://ebookmeta.com/product/front-end-reactive-architectures-
explore-the-future-of-the-front-end-using-reactive-javascript-
frameworks-and-libraries-1st-edition-luca-mezzalira/
ebookmeta.com
Primary Mathematics 3A Hoerst
https://ebookmeta.com/product/primary-mathematics-3a-hoerst/
ebookmeta.com
A New Vision for Center Based Engineering Research 1st
Edition And Medicine Engineering National Academies Of
Sciences
https://ebookmeta.com/product/a-new-vision-for-center-based-
engineering-research-1st-edition-and-medicine-engineering-national-
academies-of-sciences/
ebookmeta.com

Security Council Sanctions Governance The Power and Limits
of Rules 1st Edition Thomas Dörfler
https://ebookmeta.com/product/security-council-sanctions-governance-
the-power-and-limits-of-rules-1st-edition-thomas-dorfler/
ebookmeta.com
Math Is Everything Bliss Green
https://ebookmeta.com/product/math-is-everything-bliss-green/
ebookmeta.com
Fundamentals of Data Engineering 1st Edition Joe Reis
https://ebookmeta.com/product/fundamentals-of-data-engineering-1st-
edition-joe-reis/
ebookmeta.com
Logic Computation and Rigorous Methods Essays Dedicated to
Egon Börger on the Occasion of His 75th Birthday Lecture
Notes in Computer Science 12750 Alexander Raschke
(Editor)
https://ebookmeta.com/product/logic-computation-and-rigorous-methods-
essays-dedicated-to-egon-borger-on-the-occasion-of-his-75th-birthday-
lecture-notes-in-computer-science-12750-alexander-raschke-editor/
ebookmeta.com
Modern Architecture 1st Edition Frank Lloyd Wright
https://ebookmeta.com/product/modern-architecture-1st-edition-frank-
lloyd-wright/
ebookmeta.com

Psychoanalysis as an Ethical Process 1st Edition Robert P.
Drozek
https://ebookmeta.com/product/psychoanalysis-as-an-ethical-
process-1st-edition-robert-p-drozek/
ebookmeta.com

Chapter 4. Discovering Micro-
Frontend Architectures
In the previous chapter, we learned about decisions framework, the
foundation of any micro-frontend architecture. In this chapter, we will
review the different architecture choices, applying what we have learned so
far.
Micro-Frontend Decisions Framework
Applied
The decisions framework helps you to choose the right approach for your
micro-frontend project based on its characteristics (see Figure 4-1). Your
first decision will be between a horizontal and vertical split.
Figure 4-1. The micro-frontends decisions framework

TIP
The micro-frontends decisions framework helps you determine the best architecture for
a project.
Vertical Split
A vertical split offers fewer choices, and because they are likely well
known by frontend developers who are used to writing single-page
applications (SPAs), only the client-side choice is shown in Figure 4-1.
You’ll find a vertical split helpful when your project requires a consistent
user interface evolution and a fluid user experience across multiple views.
That’s because a vertical split provides the closest developer experience to
an SPA, and therefore the tools, best practices, and patterns can be used for
the development of a micro-frontend.
Although technically you can serve vertical-split micro-frontends with any
composition, so far all the explored implementations have a client-side
composition in which an application shell is responsible for mounting and
unmounting micro-frontends, leaving us with one composition method to
choose from. The relation between a micro-frontend and the application
shell is always one to one, so therefore the application shell loads only one
micro-frontend at a time. You’ll also want to use client-side routing. The
routing is usually split in two parts, with a global routing used for loading
different micro-frontends being handled by the application shell (see
Figure 4-2).

Figure 4-2. The application shell is responsible for global routing between micro-frontends
Although the local routing between views inside the same micro-frontend is
managed by the micro-frontend itself, you’ll have full control of the
implementation and evolution of the views present inside it since the team
responsible for a micro-frontend is also the subject-matter expert on that
business domain of the application (Figure 4-3).
Figure 4-3. A micro-frontend is responsible for routing between views available inside the micro-
frontend itself

Finally, for implementing an architecture with a vertical-split micro-
frontend, the application shell loads HTML or JavaScript as the entry point.
The application shell shouldn’t share any business domain logic with the
other micro-frontends and should be technology agnostic to allow future
system evolution, so you don’t want to use any specific UI framework for
building an application shell. Try Vanilla JavaScript if you built your own
implementation.
The application shell is always present during users’ sessions because it’s
responsible for orchestrating the web application as well as exposing some
life cycle APIs for micro-frontends in order to react when they are fully
mounted or unmounted.
When vertical-split micro-frontends have to share information with other
micro-frontends, such as tokens or user preferences, we can use query
strings for volatile data, or web storages for tokens or user preferences,
similar to how the horizontal split ones do between different views.
Horizontal Split
A horizontal split works well when a business subdomain should be
presented across several views and therefore reusability of the subdomain
becomes key for the project; when search engine optimization is a key
requirement of your project and you want to use a server-side rendering
approach; when your frontend application requires tens if not hundreds of
developers working together and you have to split more granular our
subdomains; or when you have a multitenant project with customer
customizations in specific parts of your software.
The next decision you’ll make is between client-side, edge-side, and server-
side compositions. Client side is a good choice when your teams are more
familiar with the frontend ecosystem or when your project is subject to high
traffic with significant spikes, for instance. You’ll avoid dealing with
scalability challenges on the frontend layer because you can easily cache
your micro-frontends, leveraging a content delivery network (CDN).

You can use edge-side composition for a project with static content and
high traffic in order to delegate the scalability challenge to the CDN
provider instead of having to deal with it in your infrastructure. As we
discussed in Chapter 3, embracing this architecture style has some
challenges, such as its complicated developer experience and the fact that
not all CDNs support it. But projects like online catalog with no
personalized content may be a good candidate for this approach.
Server-side composition gives us the most control of our output, which is
great for highly indexed websites, such as news sites or ecommerce. It’s
also a good choice for websites that require great performance metrics,
similar to PayPal and American Express, both of which use server-side
composition.
Next is your routing strategy. While you can technically apply any routing
to any composition, it’s common to use the routing strategy associated with
your chosen composition pattern. If you choose a client-side composition,
for example, most of the time, routing will happen at the client-side level.
You might use computation logic at the edge (using Lambda@Edge in case
of AWS or Workers in CloudFlare) to avoid polluting the application shell’s
code with canary releases or to provide an optimized version of your web
application to search engine crawlers leveraging the dynamic rendering
capability.
On the other hand, an edge-side composition will have an HTML page
associated with each view, so every time a user loads a new page, a new
page will be composed in the CDN, which will retrieve multiple micro-
frontends to create that final view. Finally, with server-side routing, the
application server will know which HTML template is associated with a
specific route; routing and composition happen on the server side.
Your composition choice will also help narrow your technical solutions for
building a micro-frontends project. When you use client-side composition
and routing, your best implementation choice is an application shell loading
multiple micro-frontends in the same view with the webpack plug-in called
Module Federation, with iframes, or with web components, for instance.

For the edge-side composition, the only solution available is using edge-
side includes (ESI). We are seeing hints that this may change in the future,
as cloud providers extend their edge services to provide more
computational and storage resources. For now, though, ESI is the only
option. And when you decide to use server-side composition, you can use
server-side includes (SSI) or one of the many SSR frameworks for your
micro-frontend applications. Note that SSRs will give you greater flexibility
and control over your implementation.
Missing from the decisions framework is the final pillar: how the micro-
frontends will communicate when they are in the same or different views.
This is mainly because when you select a horizontal split, you have to avoid
sharing any state across micro-frontends; this approach is an antipattern.
Instead, you’ll use the techniques mentioned in Chapter 3, such as an event
emitter, custom events, or reactive streams using an implementation of the
publish/subscribe (pub/sub) pattern for decoupling the micro-frontends and
maintaining their independent nature. When you have to communicate
between different views, you’ll use a query string parameter to share
volatile data, such as product identifiers, and web storage/cookies for
persistent data, such as users’ tokens or local users’ settings.
OBSERVER PATTERN
The observer pattern (also known as publish/subscribe pattern) is a
behavioral design pattern that defines a one-to-many relationship
between objects such that, when one object changes its state, all
dependent objects are notified and updated automatically. An object
with a one-to-many relationship with other objects that are interested in
its state is called the subject or publisher. Its dependent objects are
called observers or subscribers. The observers are notified whenever the
state of the subject changes, and then they act accordingly. The subject
can have any number of dependent observers.

Architecture Analysis
To help you better choose the right architecture for your project, we’ll now
analyze the technical implementations, looking at challenges and benefits.
We’ll review the different implementations in detail and then assess the
characteristics for each architecture. The characteristics we’ll analyze for
every implementation:
Deployability
Reliability and ease of deploying a micro-frontend in an environment.
Modularity
Ease of adding or removing micro-frontends and ease of integrating
with shared components hosted by micro-frontends.
Simplicity
Ease of being able to understand or do. If a piece of software is
considered simple, it has likely been found to be easy to understand and
to reason about.
Testability
Degree to which a software artifact supports testing in a given test
context. If the testability of the software artifact is high, then finding
faults in the system by means of testing is easier.
Performance
Indicator of how well a micro-frontend would meet the quality of user
experience described by web vitals, essential metrics for a healthy site.
Developer experience

The experience developers are exposed to when they use your product,
be it client libraries, SDKs, frameworks, open source code, tools, API,
technology, or services.
Scalability
The ability of a process, network, software, or organization to grow and
manage increased demand.
Coordination
Unification, integration, or synchronization of group members’ efforts
in order to provide unity of action in the pursuit of common goals.
Characteristics are rated on a five-point scale, with one point indicating that
the specific architecture characteristic isn’t well supported and five points
indicating that the architecture characteristic is one of the strongest features
in the architectural pattern. The score indicates which architecture
characteristic shines better with every approach described. It’s almost
impossible having all the characteristics working perfectly in an
architecture due to the tension they exercise with each other. Our role would
be to find the trade-off suitable for the application we have to build, hence
the decision to create a score mechanism to evaluate all of these
architectural approaches.
Architecture and Trade-offs
As I pointed out elsewhere in this book, I firmly believe that the perfect
architecture doesn’t exist; it’s always a trade-off. The trade-offs are not only
technical but also based on business requirements and organizational
structure. Modern architecture considers other forces that contribute to the
final outcome as well as technical aspects. We must recognize the
sociotechnical aspects and optimize for the context we operate in instead of
searching for the “perfect architecture” (which doesn’t exist) or borrowing

the architecture from another context without researching whether it would
be appropriate for our context.
In Fundamentals of Software Architecture, Neal Ford and Mark Richards
highlight very well these new architecture practices and invite the readers to
optimize for the “least worst” architecture. As they state, “Never shoot for
the best architecture, but rather the least worst architecture.”
Before settling on a final architecture, take the time to understand the
context you operate in, your teams’ structures, and the communication
flows between teams. When we ignore these aspects, we risk creating a
great technical proposition that’s completely unsuitable for our company.
It’s the same when we read case studies from other companies embracing
specific architectures. We need to understand how the company works and
how that compares to how our company works. Often the case studies focus
on how a company solved a specific problem, which may or may not
overlap with your challenges and goals. It’s up to you to find out if the case
study’s challenges match your own.
Read widely and talk with different people in the community to understand
the forces behind certain decisions. Taking the time to research will help
you avoid making wrong assumptions and become more aware of the
environment you are working in.
Every architecture is optimized for solving specific technical and
organizational challenges, which is why we see so many approaches to
micro-frontends. Remember: there isn’t right or wrong in architecture, just
the best trade-off for your own context.
Vertical-Split Architectures
For a vertical-split architecture, a client-side composition, client-side
routing, and an application shell, as described above, are fantastic for teams
with a solid background of building SPAs for their first foray into micro-
frontends, because the development experience will be mostly familiar. This

is probably also the easiest way to enter the micro-frontend world for
developers with a frontend background.
Application Shell
A persistent part of a micro-frontend application, the application shell is the
first thing downloaded when an application is requested. It will shepherd a
user session from the beginning to the end, loading and unloading micro-
frontends based on the endpoint the user requests. The main reasons to load
micro-frontends inside an application shell include:
Handling the initial user state (if any)
If a user tries to access an authenticated route via a deep link but the
user token is invalid, the application shell redirects the user to the sign-
in view or a landing page. This process is needed only for the first load,
however. After that, every micro-frontend in an authenticated area of a
web application should manage the logic for keeping the user
authenticated or redirecting them to an unauthenticated page.
Retrieving global configurations
When needed, the application shell should first fetch a configuration
that contains any information used across the entire user sessions, such
as the user’s country if the application provides different experiences
based on country.
Fetching the available routes and associated micro-frontends to load
To avoid needlessly deploying the application shell, the route
configurations should be loaded at runtime with the associated micro-
frontends. This will guarantee control of the routing system without
deploying the application shell multiple times.

Setting logging, observability, or marketing libraries
Because these libraries are usually applied to the entire application, it’s
best to instantiate them at the application shell level.
Handling errors if a micro-frontend cannot be loaded
Sometimes micro-frontends are unreachable due to a network issue or
bug in the system. It’s wise to add an error message (a 404 page, for
instance) to the application shell or load a highly available micro-
frontend to display errors and suggest possible solutions to the user, like
suggesting similar products or asking them to come back later.
You could achieve similar results by using libraries in every micro-frontend
rather than using an orchestrator like the application shell. However, ideally
you want just one place to manage these things from. Having multiple
libraries means ensuring they are always in sync between micro-frontends,
which requires more coordination and adds complexity to the entire
process. Having multiple libraries also creates risk in the deployment phase,
where there are breaking changes, compared to centralizing libraries inside
the application shell.
Never use the application shell as a layer to interact constantly with micro-
frontends during a user session. The application shell should only be used
for edge cases or initialization. Using it as a shared layer for micro-
frontends risks having a logical coupling between micro-frontends and the
application shell, forcing testing and/or redeployment of all micro-frontends
available in an application. This situation is also called a distributed
monolith and is a developer’s worst nightmare.
In this pattern, the application shell loads only one micro-frontend at a time.
That means you don’t need to create a mechanism for encapsulating
conflicting dependencies between micro-frontends because there won’t be

any clash between libraries or CSS styles (see Figure 4-4), as long as both
are removed from the window object when a micro-frontend is unloaded.
The application shell is nothing more than a simple HTML page with logic
wrapped in a JavaScript file. Some CSS styles may or may not be included
in the application shell for the initial loading experience, such as for
showing a loading animation like a spinner. Every micro-frontend entry
point is represented by a single HTML page containing the logic and style
of a single view or a small SPA containing several routes that include all the
logic needed to allow a user to consume an entire subdomain of the
application without a new micro-frontend needing to load. A JavaScript file
could be loaded instead as a micro-frontend entry point, but in this case we
are limited by the initial customer experience, because we have to wait until
the JavaScript file is interpreted before it can add new elements into the
domain object model (DOM).

Figure 4-4. Vertical-split architecture with client-side composition and routing using the application
shell
The vertical split works well when we want to create a consistent user
experience while providing full control to a single team. A clear sign that
this may be the right approach for your application is when you don’t have
many repetitions of business subdomains across multiple views but every
part of the application may be represented by an application itself.

Identifying micro-frontends becomes easy when we have a clear
understanding of how users interact with the application. If you use an
analytics tool like Google Analytics, you’ll have access to this information.
If you don’t have this information, you’ll need to get it before you can
determine how to structure the architecture, business domains, and your
organization. With this architecture, there isn’t a high reusability of micro-
frontends, so it’s unlikely that a vertical-split micro-frontend will be reused
in the same application multiple times.
However, inside every micro-frontend we can reuse components (think
about a design system), generating a modularity that helps avoid too much
duplication. It’s more likely, though, that micro-frontends will be reused in
different applications maintained by the same company. Imagine that in a
multitenant environment, you have to develop multiple platforms and you
want to have a similar user interface with some customizations for part of
every platform. You will be able to reuse vertical-split micro-frontends,
reducing code fragmentation and evolving the system independently based
on the business requirements.
Challenges
Of course, there will be some challenges during the implementation phase,
as with any architecture pattern. Apart from domain-specific ones, we’ll
have common challenges, some of which have an immediate answer, while
others will depend more on context. Let’s look at four major challenges: a
sharing state, the micro-frontends composition, a multiframework approach,
and the evolution of your architecture.
Sharing state
The first challenge we face when we work with micro-frontends in general
is how to share states between micro-frontends. While we don’t need to
share information as much with a vertical-split architecture, the need still
exists.

Some of the information that we may need to share across multiple micro-
frontends are fine when stored via web storage, such as the audio volume
level for media the user played or the fonts recently used to edit a
document.
When information is more sensitive, such as personal user data or an
authentication token, we need a way to retrieve this information from a
public API and then share across all the micro-frontends interested in this
information. In this case, the first micro-frontend loaded at the beginning of
the user’s session would retrieve this data, stored in a web storage with a
retrieval time stamp. Then every micro-frontend that requires this data can
retrieve it directly from the web storage, and if the time stamp is older than
a preset amount of time, the micro-frontend can request the data again. And
because the application loads only one micro-frontend at a time and every
micro-frontend will have access to the selected web storage, there is no
strong requirement to pass through the application shell for storing data in
the web storage.
However, let’s say that your application relies heavily on the web storage,
and you decide to implement security checks to validate the space available
or type of message stored. In this scenario, you may want to instead create
an abstraction via the application shell that will expose an API for storing
and retrieving data. This will centralize where the data validation happens,
providing meaningful errors to every micro-frontend in case a validation
fails.
Composing micro-frontends
You have several options for composing vertical-split micro-frontends
inside an application shell. Remember, however, that vertical-split micro-
frontends are composed and routed on the client side only, so we are limited
to what the browser’s standards offer us. There are four techniques for
composing micro-frontends on the client side:
ES modules

JavaScript modules can be used to split our applications into smaller
files to be loaded at compile time or at runtime, fully implemented in
modern browsers. This can be a solid mechanism for composing micro-
frontends at runtime using standards. To implement an ES module, we
simply define the module attribute in our script tag and the browser will
interpret it as a module:
<script type="module" src="catalogMFE.js"></script>
This module will be always deferred and can implement cross-origin
resource sharing (CORS) authentication. ES modules can also be
defined for the entire application inside an import map, allowing us to
use the syntax to import a module inside the application. As of
publication time, the main problem with import maps is that they are not
supported by all the browsers. You’ll be limited to Google Chrome,
Microsoft Edge (with Chromium engine), and recent versions of Opera,
limiting this solution’s viability.
SystemJS
This module loader supports import maps specifications, which are not
natively available inside the browser. This allows them to be used inside
the SystemJS implementation, where the module loader library makes
the implementation compatible with all the browsers. This is a handy
solution when we want our micro-frontends to load at runtime, because
it uses a syntax similar to import maps and allows SystemJS to take care
of the browser’s API fragmentation.
Module Federation

This is a plug-in introduced in webpack 5 used for loading external
modules, libraries, or even entire applications inside another one. The
plug-in takes care of the undifferentiated heavy lifting needed for
composing micro-frontends, wrapping the micro-frontends’ scope and
sharing dependencies between different micro-frontends or handling
different versions of the same library without runtime errors. The
developer experience and the implementation are so slick that it would
seem like writing a normal SPA. Every micro-frontend is imported as a
module and then implemented in the same way as a component of a UI
framework. The abstraction made by this plug-in makes the entire
composition challenge almost completely painless.
HTML parsing
When a micro-frontend has an entry point represented by an HTML
page, we can use JavaScript for parsing the DOM elements and append
the nodes needed inside the application shell’s DOM. At its simplest, an
HTML document is really just an XML document with its own defined
schema. Given that, we can treat the micro-frontend as an XML
document and append the relevant nodes inside the shell’s DOM using
the DOMParser object. After parsing the micro-frontend DOM, we then
append the DOM nodes using adoptNode or cloneNode methods.
However, using cloneNode or adoptNode doesn’t work with the script
element, because the browser doesn’t evaluate the script element, so in
this case we create a new one, passing the source file found in the
micro-frontend’s HTML page. Creating a new script element will
trigger the browser to fully evaluate the JavaScript file associated with

this element. In this way, you can even simplify the micro-frontend
developer experience because your team will provide the final results
knowing how the initial DOM will look. This technique is used by some
frameworks, such as qiankun, which allows HTML documents to be
micro-frontend entry points.
All the major frameworks composed on the client side implement these
techniques, and sometimes you even have options to pick from. For
example, with single SPA you can use ES modules, SystemJS with import
maps, or Module Federation.
All these techniques allow you to implement static or dynamic routes. In the
case of static routes, you just need to hardcode the path in your code. With
dynamic path, you can retrieve all the routes from a static JSON file to load
at the beginning of the application or create something more dynamic by
developing an endpoint that can be consumed by the application shell and
where you apply logic based on the user’s country or language for returning
the final routing list.
Multiframework approach
Using micro-frontends for a multiframework approach is a controversial
decision, because many people think that this forces them to use multiple
UI frameworks, like React, Angular, Vue, or Svelte. But what is true for
frontend applications written in a monolithic way is also true for micro-
frontends.
Although technically you can implement multiple UI frameworks in an
SPA, it creates performance issues and potential dependency clashes. This
applies to micro-frontends as well, so using a multiframework
implementation for this architecture style isn’t recommended.
Instead, follow best practices like reducing external dependencies as much
as you can, importing only what you use rather than entire packages that

may increase the final JavaScript bundle. Many JavaScript tools implement
a tree-shaking mechanism to help achieve smaller bundle sizes.
There are some use cases in which the benefits of having a multiframework
approach with micro-frontends outweigh the challenges, such as when we
can create a healthy flywheel for developers, reducing the time to market of
their business logic without affecting production traffic.
Imagine you start porting a frontend application from an SPA to micro-
frontends. Working on a micro-frontend and deploying the SPA codebase
alongside it would help you to provide value for your business and users.
First, we would have a team finding best practices for approaching the
porting (such as identifying libraries to reuse across micro-frontends),
setting up the automation pipeline, sharing code between micro-frontends,
and so on. Second, after creating the minimum viable product (MVP), the
micro-frontend can be shipped to the final user, retrieving metrics and
comparing with the older version. In a situation like this, asking a user to
download multiple UI frameworks is less problematic than developing the
new architecture for several months without understanding if the direction
is leading to a better result. Validating your assumptions is crucial for
generating the best practices shared by different teams inside your
organization. Improving the feedback loop and deploying code to
production as fast as possible demonstrates the best approach for
overcoming future challenges with microarchitectures in general.
You can apply the same reasoning to other libraries in the same application
but with different versions, such as when you have a project with an old
version of Angular and you want to upgrade to the latest version.
Remember, the goal is creating the muscles for moving at speed with
confidence and reducing the potential mistakes automating what is possible
and fostering the right mindset across the teams. Finally, these
considerations are applicable to all the micro-frontend architecture shared in
this book.
Architecture evolution and code encapsulation

Perfectly defining the subdomains on the first try isn’t always feasible. In
particular, using a vertical-split approach may result in coarse-grained
micro-frontends that become complicated after several months of work
because of broadening project scope as the team’s capabilities grow. Also,
we can have new insights into assumptions we made at the beginning of the
process. Fear not! This architecture’s modular nature helps you face these
challenges and provides a clear path for evolving it alongside the business.
When your team’s cognitive load starts to become unsustainable, it may be
time to split your micro-frontend. One of the many best practices for
splitting a micro-frontend is code encapsulation, which is based on a
specific user flow. Let’s explore it!
The concept of encapsulation comes from object-oriented programming
(OOP) and is associated with classes and how to handle data. Encapsulation
binds together the attributes (data) and the methods (functions and
procedures) that manipulate the data in order to protect the data. The
general rule, enforced by many languages, is that attributes should only be
accessed (that is, retrieved or modified) using methods that are contained
(encapsulated) within the class definition.
Imagine your micro-frontend is composed of several views, such as a
payment form, sign-up form, sign-in form, and email and password retrieval
form, as shown in Figure 4-5.
Figure 4-5. Authentication micro-frontend composed of several views that may create a high
cognitive load for the team responsible for this micro-frontend

An existing user accessing this micro-frontend is more likely to sign in to
the authenticated area or want to retrieve their account email or password,
while a new user is likely to sign up or make a payment. A natural split for
this micro-frontend, then, could be one micro-frontend for authentication
and another for subscription. In this way, you’ll separate the two according
to business logic without having to ask the users to download more code
than the flow would require (see Figure 4-6).
Figure 4-6. Splitting the authentication micro-frontend to reduce the cognitive load, following
customer experience more than technical constraints
This isn’t the only way to split this micro-frontend, but however you split it,
be sure you’re prioritizing a business outcome rather than a technical one.
Prioritizing the customer experience is the best way to provide a final
output that your users will enjoy.
Encapsulation helps with these situations. For instance, avoid having a
unique state representing the entire micro-frontend. Instead, prefer state
management libraries that allow composition of state, like MobX-State-
Tree does. The data will be expressed in tree structure, which you can
compose at will. Spend the time evaluating how to implement the
application state, and you may save time later while also reducing your
cognitive load. It is always easier to think when the code is well identified
inside some boundaries than when it’s spread across multiple parts of the
application.
When libraries or even logic are used in multiple domains, such as in a form
validation library, you have a few options:

Duplicate the code
Code duplication isn’t always a bad practice; it depends on what you are
optimizing for and overall impact of the duplicated code. Let’s say that
you have a component that has different states based on user status and
the view where it’s hosted, and that this component is subject to new
requirements more often in one domain than in others. You may want to
centralize it. Keep in mind, though, that every time you have a
centralized library or component, you have to build a solid governance
for making sure that when this shared code is updated, it also gets
updated in every micro-frontend that uses this shared code as well.
When this happens, you also have to make sure the new version doesn’t
break anything inside each micro-frontend and you need to coordinate
the activity across multiple teams. In this case, the component isn’t
difficult to implement and it will become easier to build for every team
that uses it, because there are fewer states to take care of. That allows
every implementation to evolve independently at its own speed. Here,
we’re optimizing for speed of delivery and reducing the external
dependencies for every team. This approach works best when you have
a limited amount of duplication. When you have dozens of similar
components, this reasoning doesn’t scale anymore; you’ll want to
abstract into a library instead.
Abstract your code into a shared library
In some situations, you really want to centralize the business logic to
ensure that every micro-frontend is using the same implementation, as
with integrating payment methods. Imagine implementing in your

checkout form multiple payment methods with their validation logic,
handling errors, and so on. Duplicating such a complex and delicate part
of the system isn’t wise. Creating a shared library instead will help
maintain consistency and simplify the integration across the entire
platform. Within the automation pipelines, you’ll want to add a version
check on every micro-frontend to review the latest library version.
Unfortunately, while dealing with distributed systems helps you scale
the organization and deliver with speed, sometimes you need to enforce
certain practices for the greater good.
Delegate to a backend API
The third option is to delegate the common part to be served to all your
vertical-split micro-frontends by the backend, thus providing some
configuration and implementation of the business logic to each micro-
frontend. Imagine you have multiple micro-frontends that are
implementing an input field with specific validation that is simple
enough to represent with a regular expression. You might be tempted to
centralize the logic in a common library, but this would mean enforcing
the update of this dependency every time something changes.
Considering the logic is easy enough to represent and the common part
would be using the same regular expression, you can provide this
information as a configuration field when the application loads and
make it available to all the micro-frontends via the web storage. That
way, if you want to change the regular expression, you won’t need to
redeploy every micro-frontend implementing it. You’ll just change the

regular expression in the configuration, and all the micro-frontends will
automatically use the latest implementation.
CODE DUPLICATION OVER WRONG ABSTRACTIONS
Many well-known people in the industry have started to realize that
abstracting code is not always a benefit, especially in the long run. In
certain cases, code duplication brings more benefits to a premature or a
hasty abstraction. Moreover, duplicated code can be easily abstracted if
and when needed; it’s more challenging to try to move away from
abstractions once they’re present in the code. If you are interested in
this topic, read “The Wrong Abstraction”, a 2016 blog post by Sandi
Metz. Kent Dodds’s AHA programming or “Avoid Hasty Abstractions”
concept is strongly inspired by the work Metz describes in his blog and
talk. Also, the well-known DRY principle (don’t repeat yourself)
appears to be misapplied by many developers, who just looked in the
code for duplicated lines of code and abstracted them. In the second
edition of Pragmatic Programmer (Addison-Wesley), where the DRY
principle was first introduced, the authors provide a great explanation of
this point:
In the first edition of this book we did a poor job of explaining just
what we meant by Don’t Repeat Yourself. Many people took it to refer
to code only: they thought that DRY means “don’t copy-and-paste
lines of source.”
That is part of DRY, but it’s a tiny and fairly trivial part. DRY is
about the duplication of knowledge, of intent. It’s about expressing
the same thing in two different places, possibly in two totally different
ways. [emphasis added]
It’s important to understand that no solution fits everything. Consider the
context your implementation should represent and choose the best trade-off
in the guardrails you are operating with. Could you have designed the

micro-frontends in this way from the beginning? Potentially, you could
have, but the whole point of this architecture is to avoid premature
abstractions, optimize for fast delivery, and evolve the architecture when it
is required due to complexity or just a change of direction.
Implementing a Design System
In a distributed architecture like micro-frontends, design systems may seem
a difficult feature to achieve, but in reality the technical implementation
doesn’t differ too much from that of a design system in an SPA. When
thinking about a design system applied to micro-frontends, imagine a
layered system composed of design tokens, basic components, user
interface library, and the micro-frontends that host all these parts together,
as shown in Figure 4-7.
Figure 4-7. How a design system fits inside a micro-frontends architecture
The first layer, design tokens, allows you to capture low-level values to then
create the styles for your product, such as font families, text colors, text
size, and many other characteristics used inside our final user interface.
Generally, design tokens are listed in JSON or YAML files, expressing
every detail of our design system.

We don’t usually distribute design tokens across different micro-frontends
because each team will implement them in their own way, risking the
introduction of bugs in some areas of the application and not in others,
increasing the code duplication across the system, and, in general, slowing
down the maintenance of a design system. However, there are situations
when design tokens can be an initial step for creating a level of consistency
for iterating later on, with basic components shared across all the micro-
frontends. Often, teams do not have enough space for implementing the
final design system components inside every micro-frontend. Therefore,
make sure if you go down this path that you have the time and space for
iterating on the design system.
The next layer is basic components. Usually, these components don’t hold
the application business logic and are completely unaware of where they
will be used. As a result, they should be as generic as can be, such as a label
or button, which will provide the consistency we are looking for and the
flexibility to be used in any part of the application.
This is the perfect stage for centralizing the code that will be used across
multiple micro-frontends. In this way, we create the consistency needed in
the UI to allow every team to use components at the level they need.
The third layer is a UI components library, usually a composition of basic
components that contain some business logic that is reusable inside a given
domain. We may be tempted to share these components as well, but be
cautious in doing so. The governance to maintain and the organization
structure may cause many external dependencies across teams, creating
more frustration than efficiencies. One exception is when there are complex
UI components that require a lot of iterations and there is a centralized team
responsible for them. Imagine, for instance, building a complex component
such as a video player with several functionalities, such as closed captions,
a volume bar, and trick play. Duplicating these components is a waste of
time and effort; centralizing and abstracting your code is by far more
efficient.

Note, though, that shared components are often not reused as much as we
expect, resulting in a wasted effort. Therefore, think twice before
centralizing a component. When in doubt, start duplicating the component
and, after a few iterations, review whether these components need to be
abstracted. The wrong abstraction is way more expensive than duplicated
code.
The final layer is the micro-frontend that is hosting the UI components
library. Keep in mind the importance of a micro-frontend’s independence.
The moment we get more than three or four external dependencies, we are
heading toward a distributed monolith. That’s the worst place to be because
we are treating a distributed architecture like a monolith that we wanted to
move away from, no longer creating independent teams across the
organization.
To ensure we are finding the right trade-offs between development speed
and independent teams and UI consistency, consider validating the
dependencies monthly or every two months throughout the project life
cycle. In the past, I’ve worked at companies where this exercise was done
every two weeks at the end of every sprint, and it helped many teams
postpone tasks that may not have been achievable during a sprint due to
blocks from external dependencies. In this way, you’ll reduce your teams’
frustration and increase their performance.
On the technical side, the best investment you can make for creating a
design system is in web components. Since you can use web components
with any UI framework, should you decide to change the UI framework
later, the design system will remain the same, saving you time and effort.
There are some situations in which using web components is not viable,
such as projects that have to target old browsers. Chances are, though, you
won’t have such strong requirements and you can target modern browsers,
allowing you to leverage web components with your micro-frontend
architecture.
While getting the design system ready to be implemented is half the work,
to accomplish the delivery inside your micro-frontends architecture, you’ll

need a solid governance to maintain that initial investment. Remember,
dealing with a distributed architecture is not as straightforward as you can
imagine. Usually, the first implementation happens quite smoothly because
there is time allocated to that. The problems come with subsequent updates.
Especially when you deal with distributed teams, the best approach is to
automate the system design version validation in the continuous integration
(CI) phase. Every time a micro-frontend is built, the package.json file
should check that the design system library is up to date with the latest
version.
Implementing this check in CI allows you to be as strict as needed. You
may decide to provide a warning in the logs, asking to update the version as
soon as possible, or prevent artifact creation if the micro-frontend is one or
more major versions behind.
Some companies have custom dashboards for dealing with this problem, not
only for design systems but also for other libraries, such as logging or
authentication. In this way, every team can check in real time whether their
micro-frontend implements the latest versions.
Finally, let’s consider the team’s structure. Traditionally, in enterprise
companies, the design team is centralized, taking care of all the aspects of
the design system, from ideation to delivery, and the developers just
implement the library the design team provides. However, some companies
implement a distributed model wherein the design team is a central
authority that provides the core components and direction for the entire
design system, but other teams populate the design system with new
components or new functionalities of existing ones. In this second
approach, we reduce potential bottlenecks by allowing the development
teams to contribute to the global design system. Meanwhile, we keep
guardrails in place to ensure every component respects the overall plan,
such as regular meetings between design and development, office hours
during which the design team can guide development teams, or even
collaborative sessions where the design team sets the direction but the
developers actually implement the code inside the design system.

Developer Experience
For vertical-split micro-frontends, the developer’s experience is very
similar to SPAs. However, there are a couple of suggestions that you may
find useful to think about up front. First of all, create a command line tool
for scaffolding micro-frontends with a basic implementation and common
libraries you would like to share in all the micro-frontends such as a logging
library. While not an essential tool to have from day one, it’s definitely
helpful in the long term, especially for new team members. Also, create a
dashboard that summarizes the micro-frontend version you have in different
environments. In general, all the tools you are using for developing an SPA
are still relevant for a vertical-split micro-frontend architecture. We will
discuss this topic more in depth in Chapter 7, where we review how to
create automation pipelines for micro-frontend applications.
Search Engine Optimization
Some projects require a strong SEO strategy, including micro-frontend
projects. Let’s look at two major options for a good SEO strategy with
vertical-split micro-frontends. The first one involves optimizing the
application code in a way that is easily indexable by crawlers. In this case,
the developer’s job is implementing as many best practices as possible for
rendering the entire DOM in a timely manner (usually under five seconds).
Time matters with crawlers, because they have to index all the data in a
view and also structure the UI in a way that exposes all the meaningful
information without hiding behind user interactions. Another option is to
create an HTML markup that is meaningful for crawlers to extract the
content and categorize it properly. While this isn’t impossible, in the long
run, this option may require a bit of effort to maintain for every new feature
and project enhancement.
Another option would be using dynamic rendering to provide an optimized
version of your web application for all the crawlers trying to index your
content. Google introduced dynamic rendering to allow you to redirect
crawler requests to an optimized version of your website, usually

prerendered, without penalizing the positioning of your website in the
search engine results (see Figure 4-8).
Figure 4-8. When a crawler requests a specific page, the application server should retrieve the user-
agent and serve the crawler’s requests to a prerendered version of the website, otherwise serving the
micro-frontend implementation
There are a couple of solutions for serving a prerendered version of your
application to a crawler. First, for the prerendering phase, you can create a
customized version of your website that fetches the same data of the
website your users will consume. For instance, you can create a server-side
rendering output stored in an objects storage that translates a template into
static HTML pages at compile time, maintaining the same user-facing URL
structure. Amazon S3 is a good choice for this. You can also decide to
server-side render at runtime, eliminating the need to store the static pages
and serving the crawlers a just-in-time version created ad hoc for them.
Although this solution requires some effort to implement, it allows you the
best customization and optimization for improving the final output to the
crawler.
A second option would be using an open source solution like Puppeteer or
Rendertron to scrape the code from the website created for the users and
then deploy a web server that generates static pages regularly.
After generating the static version of your website, you need to know when
the request is coming from a browser and when from a crawler. A basic

implementation would be using a regular expression that identifies the
crawler’s user-agents. A good Node.js library for that is crawler-user-
agents. In this case, after identifying the user-agent header, the application
server can respond with the correct implementation. This solution can be
applied at the edge using technologies like AWS Lambda@Edge or
Cloudflare Workers. In this case, CDNs of some cloud providers allow a
computation layer after receiving a request. Because there are some
constraints on the maximum execution time of these containers, the user-
agent identification represents a good reason for using these edge
technologies. Moreover, they can be used for additional logic, introducing
canary releases or blue-green deployment, as we will see in Chapter 6.
Performance and Micro-Frontends
Is good performance achievable in a micro-frontend architecture?
Definitely! Performance of a micro-frontend architecture, like in any other
frontend architecture, is key for the success of a web application. And a
vertical-split architecture can achieve good performance thanks to the split
of domains and, therefore, the code to be shared with a client.
Think for a moment about an SPA. Typically, the user has to download all
the code specifically related to the application, the business logic, and the
libraries used in the entire application. For simplicity, let’s imagine that an
entire application code is 500 KB. The unauthenticated area, composed of
sign-in, sign-up, the landing page, customer support, and few other views,
requires 100 KB of business logic, while the authenticated area requires 150
KB of business logic. Both use the same bundled dependencies that are
each 250 KB (see Figure 4-9).
A new user has to download all 500 KB, despite the action having to fulfill
inside the SPA. Maybe one user just wants to understand the business
proposition and visits just the landing page, another user wants to see the
payment methods available, or an authenticated user is interested mainly in
the authenticated area where the service or products are available. No
matter what users are trying to achieve, they are forced to download the
entire application.

Figure 4-9. Any user of an SPA has to download the entire application regardless of the action they
intend to perform in the application
In a vertical-split architecture, however, our unauthenticated user who
wants to see the business proposition on the landing page will be able to
download the code just for that micro-frontend, while the authenticated user
will download only the codebase for the authenticated area. We often don’t
realize that our users’ behaviors are different from the way we interpret the

application, because we often optimize the application’s performance as a
whole rather than by how users interact with the site. Optimizing our site
according to user experiences results in a better outcome.
Applying the previous example to a vertical-split architecture, a user
interested only in the unauthenticated area will download less than 100 KB
of business logic plus the shared dependencies, while an authenticated user
will download only the 250 KB plus the shared dependencies.
Clearly a new user who moves beyond the landing page will download
almost 500 KB, but this approach will still save some kilobytes if we have
properly identified the application boundaries because it’s unlikely a new
user will go through every single application view. In the worst-case
scenario, the user will download 500 KB as they would for the SPA, but this
time not everything up front. Certainly, there is additional logic to
download due to the application shell, but usually the size is only in the
double digits, making it meaningless for this example. Figure 4-10 shows
the advantages of a vertical-split micro-frontend in terms of performance.
A good practice for managing performance on a vertical-split architecture is
introducing a performance budget. A performance budget is a limit for
micro-frontends that a team is not allowed to exceed. The performance
budget includes the final bundle size, multimedia content to load, and even
CSS files. Setting a performance budget is an important part of making sure
every team optimizes its own micro-frontend properly and can even be
enforced during the CI process. You won’t set a performance budget until
later in the project, but it should be updated every time there is a
meaningful refactoring or additional features introduced in the micro-
frontend codebase.

Figure 4-10. A vertical-split micro-frontend enables the user to download only the application code
needed to accomplish the action the user is looking for
Time to display the final result to the user is a key performance indicator,
and metrics to track include time-to-interactive or first contentful paint, the
size of the final artifact, font size, and JavaScript bundle size, as well as
metrics like accessibility and SEO. A tool like Lighthouse is useful for
analyzing these metrics and is available in a command-line version to be
used in the continuous integration process. Although these metrics have
been discussed extensively for SPA optimization, bundle size may be
trickier when it comes to micro-frontends.
With vertical-split architectures, you can decide either to bundle all the
shared libraries together or to bundle the libraries for each micro-frontend.
The former can provide greater performance because the user downloads
the bundle only once, but you’ll need to coordinate the libraries to update
for every change across all the micro-frontends. While this may sound like
an easy task, it can be more complicated than you think when it happens

regularly. Imagine you have a breaking change on a specific shared UI
framework; you can’t update the new version until all the micro-frontends
have done extensive tests on the new framework version. So while we gain
in performance in this scenario, we must first overcome some
organizational challenges. The latter solution—maintaining every micro-
frontend independently—reduces the communication overhead for
coordinating the shared dependencies but might increase the content the
user must download. As seen before, however, a user may decide to stay
within the same micro-frontend for the entire session, resulting in the exact
same kilobytes downloaded.
Once again, there isn’t right or wrong in any of these strategies. Make a
decision on the requirements to fulfill and the context you operate in. Don’t
be afraid to make a call and monitor how users interact with your
application. You may discover that, overall, the solution you picked, despite
some pitfalls, is the right one for the project. Remember, you can easily
reverse this decision, so spend the right amount of time thinking which path
your project requires, but be aware that you can change direction if a new
requirement arises or the decision causes more harm than benefits.
Available Frameworks
There are some frameworks available for embracing this architecture.
However, building an application shell on your own won’t require too much
effort, as long as you keep the application shell decoupled from any micro-
frontend business logic. Polluting the application shell codebase with
domain logic is not only a bad practice but also may invalidate all effort and
investment of using micro-frontends in the long run due to code and logic
coupling.
Two frameworks that are fully embracing this architecture are single-spa
and qiankun. The concept behind single-spa is very simple: it’s a
lightweight library that provides undifferentiated heavy lifting for the
following:
Registration of micro-frontends

The library provides a root configuration to associate a micro-frontend
to a specific path of your system.
Life cycle methods
Every micro-frontend is exposed to many stages when mounted. Single-
spa allows a micro-frontend to perform the right task for the life cycle
method. For instance, when a micro-frontend is mounted, we can apply
logic for fetching an API. When unmounted, we should remove all the
listeners and clean up all DOM elements.
Single-spa is a mature library, with years of refinement and many
integrations in production. It’s open source and actively maintained and has
a great community behind it. In the latest version of the library, you can
develop horizontal-split micro-frontends, too, including server-side
rendering ones. Qiankun is built on top of single-spa, adding some
functionality from the latest releases of single-spa.
Module Federation may also be a good alternative for implementing a
vertical-split architecture, considering that the mounting and unmounting
mechanism, dependencies management, orchestration between micro-
frontends, and many other features are already available to use. Module
Federation is typically used for composing multiple micro-frontends in the
same view (horizontal split). However, nothing is preventing us from using
it for handling vertical-split micro-frontends. Moreover, it’s a webpack
plug-in. If your projects are already using webpack, it may help you avoid
learning new frameworks for composing and orchestrating your project’s
micro-frontends. In the next chapter, we will explore the Module Federation
for implementing vertical and horizontal split architectures.
Use Cases
The vertical-split architecture is a good solution when your frontend
developers have experience with SPA development. It will also scale up to a

certain extent, but if you have hundreds of frontend developers working on
the same frontend application, a horizontal split may suit your project
better, because you can modularize your application even further.
Vertical-split architecture is also great when you want UI and UX
consistency. In this situation, every team is responsible for a specific
business domain, and a vertical split will allow them to develop an end-to-
end experience without the need to coordinate with other teams.
Another reason to choose this architecture pattern is the level of reusability
you want to have across multiple micro-frontends. For instance, if you reuse
mainly components of your design system and some libraries, like logging
or payments, a vertical split may be a great architecture fit. However, if part
of your micro-frontend is replicated in multiple views, a horizontal split
may be a better solution. Again, let the context drive the decision for your
project.
Finally, this architecture is my first recommendation when you start
embracing micro-frontends because it doesn’t introduce too much
complexity. It has a smooth learning curve for frontend developers, it
distributes the business domains to dozens of frontend developers without
any problem, and it doesn’t require huge upfront investment in tools but
more in general in the entire developer experience.
Architecture Characteristics
Deployability (5/5)
Because every micro-frontend is a single HTML page or an SPA, we
can easily deploy our artifacts on a cloud storage or an application
server and stick a CDN in front of it. It’s a well-known approach, used
for several years by many frontend developers for delivering their web
applications. Even better, when we apply a multi-CDN strategy, our

content will always be served to our user no matter which fault a CDN
provider may have.
Modularity (2/5)
This architecture is not the most modular. While we have a certain
degree of modularization and reusability, it’s more at the code level,
sharing components or libraries but less on the features side. For
instance, it’s unlikely a team responsible for the development of the
catalog micro-frontend shares it with another micro-frontend. Moreover,
when we have to split a vertical-split micro-frontend in two or more
parts because of new features, a bigger effort will be required for
decoupling all the shared dependencies implemented, since it was
designed as a unique logical unit.
Simplicity (4/5)
Taking into account that the primary aim of this approach is reducing
the team’s cognitive load and creating domain experts using well-known
practices for frontend developers, the simplicity is intrinsic. There aren’t
too many mindset shifts or new techniques to learn to embrace this
architecture. The overhead for starting with single-spa or Module
Federation should be minimal for a frontend developer.
Testability (4/5)
Compared to SPAs, this approach shows some weakness in the
application shell’s end-to-end testing. Apart from that edge case,
however, testing vertical-split micro-frontends doesn’t represent a

challenge with existing knowledge of unit, integration, or end-to-end
testing.
Performance (4/5)
You can share the common libraries for a vertical-split architecture,
though it requires a minimum of coordination across teams. Since it’s
very unlikely that you’ll have hundreds of micro-frontends with this
approach, you can easily create a deployment strategy that decouples
the common libraries from the micro-frontend business logic and
maintains the commonalities in sync across multiple micro-frontends.
Compared to other approaches, such as server-side rendering, there is a
delay on downloading the code of a micro-frontend because the
application shell should initialize the application with some logic. This
may impact the load of a micro-frontend when it’s too complex or
makes many roundtrips to the server.
Developer experience (4/5)
A team familiar with SPA tools won’t need to shift their mindset to
embrace the vertical split. There may be some challenges during end-to-
end testing, but all the other engineering practices, as well as tools,
remain the same. Not all the tools available for SPA projects are suitable
for this architecture, so your developers may need to build some internal
tools to fill the gaps. However, the out-of-the-box tools available should
be enough to start development, allowing your team to defer the
decisions to build new tools.
Scalability (5/5)

Other documents randomly have
different content

"You were always very obliging, Roswell," said Richard, good-
humoredly.
Roswell did not appear to appreciate this compliment. He probably
thought it savored of irony.
"Do you want to buy anything this morning?" he said, shortly.
"Yes; I would like to look at some books of fairy stories."
"For your own reading, I suppose," said Roswell.
"I may read them, but I am getting them for my ward."
"Is he a boot-black?" sneered Roswell, who knew all about Dick's
early career.
"No," said Richard, "he's a match boy; so if you've got any books
that you can warrant to be just the thing for match boys, I should
like to see them."
"We don't have many customers of that class," said Roswell,
unpleasantly. "They generally go to cheaper establishments, when
they are able to read."
"Do they?" said Dick. "I'm glad you've got into a place where you
only meet the cream of society," and Dick glanced significantly at a
red-nosed man who came in to buy a couple of sheets of notepaper.
Roswell colored.
"There are some exceptions," he said, and glanced pointedly at
Richard Hunter himself.
"Well," said Dick, after looking over a collection of juvenile books,
"I'll take these two."
He drew out his pocket-book, and handed Roswell a ten-dollar bill.
Roswell changed it with a feeling of jealousy and envy. He was the
"son of a gentleman," as he often boasted, but he never had a ten-
dollar bill in his pocket. Indeed, he was now working for six dollars a
week, and glad to get that, after having been out of a situation for
several months.

Just then Mr. Gladden, of the large down-town firm of Gladden &
Co., came into the store, and, seeing Richard, saluted him cordially.
"How are you this morning, Mr. Hunter?" he said. "Are you on your
way down town?"
"Yes, sir," said Richard.
"Come with me. We will take an omnibus together;" and the two
walked out of the store in familiar conversation.
"I shouldn't think such a man as Mr. Gladden would notice a low
boot-black," said Roswell, bitterly.
The rest of the day he was made unhappy by the thought of Dick's
prosperity, and his own hard fate, in being merely a clerk in a
bookstore with a salary of six dollars a week.

CHAPTER XV.
MARK GETS A PLACE.
In a week from the purchase of the books, Mark felt that he was
fully recovered. He never had much color, but the unhealthy pallor
had left his cheeks, and he had an excellent appetite.
"Well, Mark, how do you feel to-night?" asked Richard, on his return
from the store one evening.
"I'm all right, now, Mr. Hunter. I think I will go to work to-morrow
morning."
"What sort of work?"
"Selling matches."
"Do you like to sell matches?"
"I like it better than selling papers, or blacking boots."
"But wouldn't you like better to be in a store?"
"I couldn't get a place," said Mark.
"Why not?"
"My clothes are ragged," said the match boy with some hesitation.
"Besides I haven't got anybody to refer to."
"Can't you refer to your guardian?" asked Richard Hunter, smiling.
"Do you think I had better try to get a place in a store, Mr. Hunter?"
asked Mark.
"Yes, I think it would be much better for you than to sell matches on
the street. You are not a strong boy, and the exposure is not good

for you. As to your clothes, we'll see if we cannot supply you with
something better than you have on."
"But," said Mark, "I want to pay for my clothes myself. I have got
ten dollars in the bank at the Newsboys' Lodge."
"Very well. You can go down to-morrow morning and get it. But we
needn't wait for that. I will go and get you some clothes before I go
to business."
In the morning Richard Hunter went out with the match boy, and for
twenty dollars obtained for him a very neat gray suit, besides a
supply of under-clothing. Mark put them on at once, and felt not a
little pleased with the improvement in his appearance.
"You can carry your old clothes to Mr. O'Connor," said Richard. "They
are not very good, but they are better than none, and he may have
an opportunity of giving them away."
"You have been very kind to me, Mr. Hunter," said Mark, gratefully.
"Good-by."
"Good-by? What makes you say that?"
"Because I am going now to the Newsboys' Lodge."
"Yes, but you are coming back again."
"But I think I had better go there to live now. It will be much
cheaper, and I ought not to put you to so much expense."
"You're a good boy, Mark, but you must remember that I am your
guardian, and am to be obeyed as such. You're not going back to
the Lodge to live. I have arranged to have you stay with me at my
boarding-place. As soon as you have got a place you will work in the
daytime, and every Saturday night you will bring me your money. In
the evening I shall have you study a little, for I don't want you to
grow up as ignorant as I was at your age."
"Were you ignorant, Mr. Hunter?" asked Mark, with interest.

"Yes, I was," said Richard. "When I was fourteen, I couldn't read nor
write."
"I can hardly believe that, Mr. Hunter," said Mark. "You're such a fine
scholar."
"Am I?" asked Richard, smiling, yet well pleased with the
compliment.
"Why, you can read French as fast as I can read English, and write
beautifully."
"Well, I had to work hard to do it," said Richard Hunter. "But I feel
paid for all the time I've spent in trying to improve myself.
Sometimes I've thought I should like to spend the evening at some
place of amusement rather than in study; but if I had, there'd be
nothing to show for it now. Take my advice, Mark, and study all you
can, and you'll grow up respectable and respected."
"Now," he added, after a pause, "I'll tell you what you may do. You
may look in my 'Herald' every morning, and whenever you see a boy
advertised for you can call, or whenever, in going along the street,
you see a notice 'Boy wanted,' you may call in, and sooner or later
you'll get something. If they ask for references, you may refer to
Richard Hunter, book-keeper for Rockwell & Cooper."
"Thank you, Mr. Hunter," said Mark. "I will do so."
On parting with his guardian the match boy went down town to the
Lodging House. The superintendent received him kindly.
"I didn't know what had become of you, Mark," he said. "If it had
been some of the boys, I should have been afraid they had got into
a scrape, and gone to the Island. But I didn't think that of you."
"I hope you'll never hear that of me, Mr. O'Connor," said Mark.
"I hope not. I'm always sorry to hear of any boy's going astray. But
you seem to have been doing well since I saw you;" and the
superintendent glanced at Mark's new clothes.

"I've met with some kind friends," said the match boy. "I have been
sick, and they took care of me."
"And now you have come back to the Lodge."
"Yes, but not to stay. I came for the money that I have saved up in
the bank. It is going for these clothes."
"Very well. You shall have it. What is the name of the friend who has
taken care of you?"
"Richard Hunter."
"I know him," said the superintendent. "He is an excellent young
man. You could not be in better hands."
On leaving the Lodge Mark felt a desire to find his old ally, Ben
Gibson, who, though rather a rough character, had been kind to him.
Ben was not difficult to find. During business hours he was generally
posted on Nassau Street, somewhere between Fulton Street and
Spruce Street.
He was just polishing off a customer's boots when Mark came up,
and touched him lightly on the shoulder. Ben looked up, but did not
at first recognize the match boy in the neatly dressed figure before
him.
"Shine yer boots!" he asked, in a professional tone.
"Why, Ben, don't you know me?" asked Mark, laughing.
"My eyes, if it aint Mark, the match boy!" exclaimed Ben, in surprise.
"Where've you been all this while, Mark?"
"I've been sick, Ben."
"I'd like to be sick too, if that's the way you got them clo'es. I didn't
know what had 'come of you."
"I found some good friends," said Mark.
"If your friends have got any more good clo'es they want to get rid
of," said Ben, "tell 'em you know a chap that can take care of a few.

Are you in the match business now?"
"I haven't been doing anything for three weeks," said Mark.
"Goin' to sell matches again?"
"No."
"Sellin' papers?"
"No, I'm trying to find a place in a store."
"I don't think I'd like to be in a store," said Ben, reflectively. "I'm
afraid my delicate constitution couldn't stand the confinement.
Besides, I'm my own boss now, and don't have nobody to order me
round."
"But you don't expect to black boots all your life, Ben, do you?"
"I dunno," said Ben. "Maybe when I'm married, I'll choose some
other business. It would be rather hard to support a family at five
cents a shine. Are you comin' to the Lodge to-night?"
"No," said Mark, "I'm boarding up at St. Mark's Place."
"Mother Watson hasn't opened a fashionable boardin'-house up
there, has she?"
"I guess not," said Mark, smiling. "I can't think what has become of
her. I haven't seen her since the day she tried to carry me off."
"I've heard of her," said Ben. "She's stoppin' with some friends at the
Island. They won't let her come away on account of likin' her
company so much."
"I hope I shall never see her again," said Mark, with a shudder. "She
is a wicked old woman. But I must be going, Ben."
"I s'pose you'll come and see a feller now and then."
"Yes, Ben, when I get time. But I hope to get a place soon."
Mark walked leisurely up Broadway. Having been confined to the
house for three weeks, he enjoyed the excitement of being out in
the street once more. The shop windows looked brighter and gayer

than before, and the little match boy felt that the world was a very
pleasant place after all.
He had passed Eighth Street before he was fairly aware of the
distance he had traversed. He found himself looking into the window
of a bookstore. While examining the articles in the window his eye
suddenly caught the notice pasted in the middle of the glass on a
piece of white paper:—
"BOY WANTED."
"Perhaps they'll take me," thought Mark, suddenly. "At any rate I'll
go in and see."
Accordingly he entered the store, and looked about him a little
undecidedly.
"Well, sonny, what do you want?" asked a clerk.
"I see that you want a boy," said Mark.
"Yes. Do you want a place?"
"I am trying to get one."
"Well, go and see that gentleman about it."
He pointed to a gentleman who was seated at a desk in the corner
of the store.
"Please, sir, do you want a boy?" he asked.
"Yes," said the gentleman. "How old are you?"
"Ten years old."
"You are rather young. Have you been in any place before?"
"No, sir."
"Do you know your way about the city pretty well?"
"Yes, sir."
"I want a boy to deliver papers and magazines, and carry small
parcels of books. Do you think you could do that?"

"Yes, sir."
"Without stopping to play on the way?"
"Yes, sir."
"I have just discharged one boy, because he was gone an hour and
a half on an errand to Twentieth Street. You are the first boy that
has answered my advertisement. I'll try you on a salary of three
dollars a week, if you can go to work at once. What is your name?"
"Mark Manton."
"Very well, Mark. Go to Mr. Jones, behind the counter there, and he
will give you a parcel to carry to West Twenty-First Street."
"I'm in luck," thought Mark. "I didn't expect to get a place so easily."

CHAPTER XVI.
MARK'S FIRST IMPRESSIONS.
Probably my readers already understand that the bookstore in
which Mark has secured a place is the same in which Roswell
Crawford is employed. This circumstance, if Mark had only known it,
was likely to make his position considerably less desirable than it
would otherwise have been. Mr. Baker, the proprietor of the store,
was very considerate in his treatment of those in his employ, and Mr.
Jones, his chief clerk, was good-natured and pleasant. But Roswell
was very apt to be insolent and disagreeable to those who were, or
whom he considered to be, in an inferior position to himself, while
his lofty ideas of his own dignity and social position as the "son of a
gentleman," made him not very desirable as a clerk. Still he had
learned something from his bad luck thus far. He had been so long in
getting his present place, that he felt it prudent to sacrifice his pride
in some extent for the sake of retaining it. But if he could neglect his
duties without attracting attention, he resolved to do it, feeling that
six dollars was a beggarly salary for a young gentleman of his
position and capacity. It was unfortunate for him, and a source of
considerable annoyance, that he could get no one except his mother
to assent to his own estimate of his abilities. Even his Cousin Gilbert,
who had been Rockwell & Cooper's book-keeper before Richard
Hunter succeeded to the position, did not conceal his poor opinion of
Roswell; but this the latter attributed to prejudice, being persuaded
in his own mind that his cousin was somewhat inclined to be envious
of his superior abilities.
At the time that Mark was so suddenly engaged by Mr. Baker,
Roswell had gone out to dinner. When he returned, Mark had gone

out with the parcel to West Twenty-first Street. So they missed each
other just at first.
"Well, Crawford," said Mr. Jones, as Roswell re-entered the store,
"Mr. Baker has engaged a new boy."
"Has he? What sort of a fellow is he?"
"A little fellow. He doesn't look as if he was more than ten years
old."
"Where is he?"
"Mr. Baker sent him on an errand to Twenty-first Street."
"Humph!" said Roswell, a little discontented, "I was going to
recommend a friend of mine."
"There may be a chance yet. This boy may not suit."
In about five minutes Mr. Baker and Mr. Jones both went out to
dinner. It was the middle of the day, when there is very little
business, and it would not be difficult for Roswell to attend to any
customers who might call.
As soon as he was left alone, Roswell got an interesting book from
the shelves, and, sitting down in his employer's chair, began to read,
though this was against the rules in business hours. To see the
pompous air with which Roswell threw himself back in his chair, it
might have been supposed that he was the proprietor of the
establishment, though I believe it is true, as a general rule, that
employers are not in the habit of putting on so many airs, unless the
position is a new one, and they have not yet got over the new
feeling of importance which it is apt to inspire at first.
While Roswell was thus engaged Mark returned from his errand.
He looked about him in some uncertainty on entering the store, not
seeing either Mr. Baker or the chief clerk.
"Come here," said Roswell, in a tone of authority.
Mark walked up to the desk.

"So you are the new boy?" said Roswell, after a close scrutiny.
"Yes."
"It would be a little more polite to say 'Yes sir.'"
"Yes, sir."
"What is your age?"
"Ten years."
"Humph! You are rather young. If I had been consulted I should
have said 'Get a boy of twelve years old.'"
"I hope I shall suit," said Mark.
"I hope so," said Roswell, patronizingly. "You will find us very easy to
get along with if you do your duty. We were obliged to send away a
boy this morning because he played instead of going on his errands
at once."
Mark could not help wondering what was Roswell's position in the
establishment. He talked as if he were one of the proprietors; but his
youthful appearance made it difficult to suppose that.
"What is your name?" continued Roswell.
"Mark Manton."
"Have you been in any place before?"
"No, sir."
"Do you live with your parents?"
"My parents are dead."
"Then whom do you live with?"
"With my guardian."
"So you have a guardian?" said Roswell, a little surprised. "What is
his name?"
"Mr. Hunter."

"Hunter!" repeated Roswell, hastily. "What is his first name?"
"Richard I believe."
"Dick Hunter!" exclaimed Roswell, scornfully, "Do you mean to say
that he has charge of you?"
"Yes," said Mark, firmly, for he perceived the tone in which his friend
was referred to, and resented it. Moreover the new expression which
came over Roswell's face brought back to his recollection the
evening when, for the first time in his life, he had begged in Fulton
Market, and been scornfully repulsed by Roswell and his mother.
Roswell's face had at first seemed familiar to him, but it was only
now that he recognized him. Roswell, on the other hand, was not
likely to identify the neatly dressed boy before him with the shivering
little beggar of the market. But it recurred to him all at once that
Dick had referred to his ward as a match boy.
"You were a match boy?" he said, in the manner of one making a
grave accusation.
"Yes, sir."
"Then why didn't you keep on selling matches, and not try to get a
place in a respectable store?"
"Because Mr. Hunter thought it better for me to go into a store."
"Mr. Hunter! Perhaps you don't know that your guardian, as you call
him, used to be a boot-black."
"Yes, he told me so."
"They called him 'Ragged Dick' then," said Roswell, turning up his
nose. "He couldn't read or write, I believe."
"He's a good scholar now," said Mark.
"Humph! I suppose he told you so. But you mustn't believe all he
tells you."
"He wouldn't tell anything but the truth," said Mark, who was bolder
in behalf of his friend than he would have been for himself.

"So he did tell you he was a good scholar? I thought so."
"No, he told me nothing about it; but since I have lived with him I've
heard him read French as well as English."
"Perhaps that isn't saying much," said Roswell, with a sneer. "Can
you read yourself?"
"Yes."
"That is more than I expected. What induced Mr. Baker to take a boy
from the street is more than I can tell."
"I suppose I can run errands just as well, if I was once a match
boy," said Mark, who did not fancy the tone which Roswell assumed
towards him, and began to doubt whether he was a person of as
much importance as he at first supposed.
"We shall see," said Roswell, loftily. "But there's one thing I'll advise
you, young man, and that is, to treat me with proper respect. You'll
find it best to keep friends with me. I can get you turned away any
time."
Mark hardly knew whether to believe this or not. He already began
to suspect that Roswell was something of a humbug, and though it
was not in his nature to form a causeless dislike, he certainly did not
feel disposed to like Roswell. He did not care as much for any
slighting remarks upon himself, as for the scorn with which Roswell
saw fit to speak of his friend, Richard Hunter, who by his good
offices had won the little boy's lasting gratitude. Mark did not reply
to the threat contained in these last words of Roswell.
"Is there anything for me to do?" he asked.
"Yes, you may dust off those books on the counter. There's the
duster hanging up."
This was really Roswell's business, and he ought to have been at
work in this way instead of reading; but it was characteristic of him
to shift his duties upon others. He was not aware of how much time
had passed, and supposed that Mark would be through before Mr.

Barker returned. But that gentleman came in while Roswell was
busily engaged in reading.
"Is that the way you do your work, Roswell?" asked his employer.
Roswell jumped to his feet in some confusion.
"I thought I had better set the new boy to work," he said.
"Dusting the books is your work, not his."
"He was doing nothing, sir."
"He will have plenty to do in carrying out parcels. Besides, I don't
know that it is any worse for him to be idle than you. You were
reading also, which you know is against the rules of the store."
Roswell made no reply, but it hurt his pride considerably to be
censured thus in presence of Mark, to whom he had spoken with
such an assumption of power and patronage.
"I wish I had a store of my own," he thought, discontentedly. "Then
I could do as I pleased without having anybody to interfere with
me."
But Roswell did not understand, and there are plenty of boys in the
same state of ignorance, that those who fill subordinate positions
acceptably are most likely to rise to stations where they will
themselves have control over others.
"I suppose you have not been to dinner," said Mr. Baker, turning to
Mark.
"No, sir."
"You board in St. Mark's Place, I think you said?"
"Yes, sir."
"Very well, here is a parcel to go to East Ninth Street. You may call
and leave that at the address marked upon it, and may stay out long
enough for dinner. But don't be gone more than an hour in all."
"No, sir."

"I am glad that boy isn't my employer," thought Mark, referring of
course to Roswell Crawford, who, by the way, would have been
indignant at such an appellation. "I like Mr. Baker a great deal
better."
Mark was punctual to his appointment, and in a little less than an
hour reported himself at the store again for duty.

CHAPTER XVII.
BAD ADVICE.
Roswell pursued his way home with a general sense of discontent.
Why should he be so much worse off than Richard Hunter, who had
only been a ragged boot-black three years before? The whole world
seemed to be in a conspiracy to advance Richard, and to keep him
down. To think he should be only earning six dollars a week, while
Dick, whom he considered so far beneath him, was receiving twenty,
was really outrageous. And now he had pushed a low dependent of
his into Baker's store where Roswell was obliged to associate with
him!
Certainly Roswell's grievances were numerous. But there was one
thing he did not understand, that the greatest obstacle to his
advancement was himself. If he had entered any situation with the
determination to make his services valuable, and discharge his
duties, whatever they might be, with conscientious fidelity, he would
have found his relations with his employer much more agreeable and
satisfactory.
Mrs. Crawford still kept the house in Clinton Place, letting nearly all
the rooms to lodgers. In this way she succeeded in making both
ends meet, though with considerable difficulty, so that she had not
the means to supply Roswell with the spending money he desired.
Her nephew, James Gilbert, Richard Huntley's predecessor as book-
keeper, still boarded with her. It will be remembered by the readers
of "Fame and Fortune," that this Gilbert, on being questioned by Mr.
Rockwell as to his share in the plot against Dick, had angrily
resigned his position, thinking, probably, that he should lose it at any
rate.

It so happened that business was generally depressed at this time,
and it was three months before he succeeded in obtaining another
place, and then he was compelled to work for eight hundred dollars,
or two hundred less than he had formerly received. This was a great
disappointment to him, and did not help his temper much, which
had never been very sweet. He felt quite exasperated against Dick,
whom, very much against his wishes, he had seen the means of
promoting to his own place. Indeed, on this point, he sympathized
heartily with Roswell, whose dislike to Richard Hunter has already
been shown.
"Well, mother," said Roswell, as he entered Mrs. Crawford's
presence, "I'm getting tired of Baker's store."
"Don't say so, Roswell," said his mother, in alarm. "Remember how
long it took you to get the place."
"I have to work like a dog for six dollars a week," said Roswell.
"Yes," said his cousin, with a sneer, "that's precisely the way you
work. Dogs spend their time running round the street doing
nothing."
"Well, I have to work hard enough," said Roswell, "but I wouldn't
mind that so much, if I didn't have to associate with low match
boys."
"What do you mean, Roswell?" asked his mother, who did not
understand the allusion.
"Baker hired a new boy to-day, and who do you think he turns out to
be?"
"Not that boy, Ragged Dick?"
"No, you don't think he would give up Cousin James' place, where he
gets a thousand dollars a year, to go into Baker's as boy?"
"Who was it, then?"
"He used to be a ragged match boy about the streets. Dick Hunter
picked him up somewhere, and got him a situation in our store, on

purpose to spite me, I expect."
As the reader is aware, Roswell was mistaken in his supposition, as
Mark obtained the place on his own responsibility.
"The boot-black seems to be putting on airs," said Mrs. Crawford.
"Yes, he pretends to be the guardian of this match boy."
"What's the boy's name?"
"Mark Manton."
"If I were Mr. Baker," said Mrs. Crawford, "I should be afraid to take
a street boy into my employ. Very likely he isn't honest."
"I wish he would steal something," said Roswell, not very charitably.
"Then we could get rid of him, and the boot-black would be pretty
well mortified about it."
"He'll be found out sooner or later," said Mrs. Crawford. "You may
depend on that. You'd better keep a sharp lookout for him, Roswell.
If you catch him in stealing, it will help you with Mr. Baker, or ought
to."
This would have comforted Roswell more, but that he was privately
of opinion that Mark was honest, and would not be likely to give him
any chance of detecting him in stealing. Still, by a little management
on his part, he might cause him to fall under suspicion. It would of
course be miserably mean on his part to implicate a little boy in a
false charge; but Roswell was a mean boy, and he was not
scrupulous where his dislike was concerned. He privately decided to
think over this new plan for getting Mark into trouble.
"Isn't dinner ready, mother?" he asked, rather impatiently.
"It will be in about ten minutes."
"I'm as hungry as a bear."
"You can always do your part at the table," said his cousin
unpleasantly.
"I don't know why I shouldn't. I have to work hard enough."

"You are always talking about your hard work. My belief is that you
don't earn your wages."
"I should think it was a pity if I didn't earn six dollars a week," said
Roswell.
"Come, James, you're always hard on Roswell," said Mrs. Crawford.
"I am sure he has hard times enough without his own relations
turning against him."
James Gilbert did not reply. He was naturally of a sarcastic turn, and,
seeing Roswell's faults, was not inclined to spare them. He might
have pointed them out, however, in a kindly manner, and then his
young cousin might possibly been benefited; but Gilbert felt very
little interest in Roswell.
Immediately after dinner Roswell took up his cap. His mother
observed this, and inquired, "Where are you going, Roswell?"
"I'm going out to walk."
"Why don't you go with your cousin?"
James Gilbert had also taken his hat.
"He don't want to be bothered with me," said Roswell, and this
statement Gilbert did not take the trouble to contradict.
"Why can't you stay in and read?"
"I haven't got anything to read. Besides I've been cooped up in the
store all day, and I want to breathe a little fresh air."
There was reason in this, and his mother did not gainsay it, but still
she felt that it was not quite safe for a boy to spend his evenings out
in a large city, without any one to look after him.
Roswell crossed Broadway, and, proceeding down Eighth Street, met
a boy of about his own age in front of the Cooper Institute.
"How long have you been waiting, Ralph?" he asked.
"Not long. I only just came up."

"I couldn't get away as soon as I expected. Dinner was rather late."
"Have a cigar, Roswell?" asked Ralph.
"Yes," said Roswell, "I don't mind."
"You'll find these cigars pretty good. I paid ten cents apiece."
"I don't see how you can afford it," said Roswell. "Your cigars must
cost you considerable."
"I don't always buy ten-centers. Generally I pay only five cents."
"Well, that mounts up when you smoke three or four in a day. Let
me see, what wages do you get?"
"Seven dollars a week."
"That's only a dollar more than I get," said Roswell.
"I know one thing, it's miserably small," said Ralph. "We ought to
get twice what we do."
"These shop-keepers are awfully mean," said Roswell, beginning to
puff away at his cigar.
"That's so."
"But still you always seem to have plenty of money. That's what
puzzles me," said Roswell. "I'm always pinched. I have to pay my
mother all my wages but a dollar a week. And what's a dollar?" he
repeated, scornfully.
"Well," said Ralph, "my board costs me all but a dollar. So we are
about even there."
"Do you pay your board out of your earnings?"
"I have to. My governor won't foot the bills, so I have to."
"Still you seem to have plenty of money," persisted Roswell.
"Yes, I look out for that," said Ralph Graham, significantly.
"But I don't see how you manage. I might look out all day, and I
wouldn't be any the better off."

Building Micro-Frontends: Scaling Teams and Projects Empowering Developers 1st Edition Luca Mezzalira

Recommended

More Related Content

Similar to Building Micro-Frontends: Scaling Teams and Projects Empowering Developers 1st Edition Luca Mezzalira (20)

Recently uploaded (20)

Building Micro-Frontends: Scaling Teams and Projects Empowering Developers 1st Edition Luca Mezzalira