micro-frontend-part-two.

md 8/19/2019

Microfrontends
Software architecture should never be an end goal, but a means to an end

The economy is powered by the bytes today and in byte economy, the focus is on quickly bringing product to
market. In competitive and disrupting decade of startups where we see software companies becoming some of
the worlds most valuable companies ever created, startups spawns and dies every day. To stay alive, sustain and
gain substantial chunk of market share we want the factory running at top speed to produce software. These
factories consist of sentient human coders, who are working relentlessly to churning out feature after feature to
deliver a user story which is composite part of total structure of software product.

Microservices and Distributed Big Balls of Mud

In the beginning....

We have ancient monolithic systems, where everything is bundled up inside a single deployable unit. This is in all
probability wherever most of the trade is. Caveats apply, however monoliths may be designed quickly and area
unit simple to deploy, but they provide limited agility because even tiny changes require a full redeployment. We
additionally understand that monoliths usually find yourself trying sort of a huge ball of mud as a result of the
means that software system usually evolves over time. For example, several monolithic systems are engineered
employing a stratified design, and it's comparatively simple for stratified architectures to be abused (e.g. skipping
"around" a service to access the repository/data access layer directly).

The application we are working on is a big client facing web application. Since the initial conception of the
product, we have identified a couple of self-contained features and created micro services to provide each
functionality. We have carved out bare essentials for providing the user interface, which is our public facing web
frontend. This micro service only has one functionality which is providing the user interface. It may be scaled and
deployed become independent from the composite backend services.

1/9
micro-frontend-part-two.md 8/19/2019

If you can't build a monolith, what makes you think microservices are the answer?

If we talk about micro services in technical sense, compute, storage and network has become dirt cheap today,
and cost is rapidly declining, this trend has led to rise of development of tiny, independent full stack software
which is simply the evolution of light weight Service Oriented Architectures if done right.

Microservices have rejuvenated the age old idea of building smaller, loosely coupled , reusable piece of software
that does one thing and one thing well, emphasising on shortest time to market and minimal cost. Again, caveats
apply however, if done well, service-based architectures buy you a lot of flexibility and agility because each
service can be developed, tested, deployed, scaled, upgraded and rewritten separately, particularly if the services
area unit decoupled via asynchronous electronic messaging. The draw back is raised complexness as a result of
your software currently has more moving elements than a stone.

The complexity is still there, you're just moving it somewhere else.

Thus the same old concept just replace all in-memory function calls or shared library calls with remote network
calls, now we can independently build, change, deploy and scale them with independent teams, who don’t have
to be compelled to understand the existence of different teams.

When you have an enormous monolithic frontend that can’t be split simply, you have to think about making it
smaller. You can decompose the frontend into separate parts severally developed by completely different groups.

When you are implementing a microservices architecture you want to keep services small. This should
also apply to the frontend. If you don't, you will only reap the benefits of microservices for the backend
services. An easy solution is to split your application up into separate frontends.

We have multiple teams that work on different applications. However you’re not quite there yet: The frontend is
still a monolith that spans the different backends. This means on the frontend you still have some of the same
problems you had before switching to microservices. The image below shows a simplification of the current
architecture.

Backend teams can't deliver business value without the frontend being updated since an API without a user
interface doesn't do much. More backend groups suggests that a lot of new options, and therefore more
pressure is put on the frontend team(s) to integrate new features. To compensate for this it is possible to make
the frontend team bigger or have multiple teams working on the same project. Because the frontend still has to

2/9
micro-frontend-part-two.md 8/19/2019

be deployed in one go, teams cannot work independently. Changes have to be integrated in the same project
and the whole project needs to be tested since a change can break other features.This would basically mean
that the teams are not working independently.

With a monolithic frontend you never get the pliability to scale across groups as assured by microservices.
Besides not being able to scale, there is also the classical overhead of a separate backend and frontend team.
Each time there is a breaking change in the API of one of the services, the frontend has to be updated. Especially
when a feature is added to a service, the frontend has to be updated to ensure your customers can even use the
feature.

If you have a frontend small enough it can be maintained by a team which is also responsible for one or more
services which are coupled to the frontend. This means that there is no overhead in cross team communication.
But because the frontend and the backend can not be worked on independently, you are not really doing
microservices.

3/9
micro-frontend-part-two.md 8/19/2019

If you do have multiple teams working on your platform, but you were to have multiple smaller frontend
applications there would have been no problem. Each frontend would act as the interface to one or more
services. Each of these services will have their own persistence layer. This is known as vertical decomposition.
Now the major problem with achieving this kind of architecture with frontend is User Experience End users of the
a modern application product today, have this perception of one company means one website. However, as we
discussed above, this approach becomes a development bottleneck and doesn't scale efficiently.

We will discuss some of the most popular ways to do the vertical decomposition for the frontend in order to
achieve following objectives:

Team Ownership
Develop Independently
Run Independently
Technology Agnostic
Fast Loading
Native Support
Sharing Basics
Modular
Corporate Identity
Smooth User Interaction

4/9
micro-frontend-part-two.md 8/19/2019

Hardcore Nginx Based Routing

What we can do if we want to get started with spliting our monolithic frontend Singe Page Application , into
multiple standalone Single Page Applications served behind the nginx, running independently.

We can hyperlink different applications, however each application would require to maintain similar Base
Application templates in there code in order to achieve brand identity.

As you can see, this approach is okay to start with however four of the very critical cases are failing here.

Passed Failed

Team Ownership Sharing Basics

Develop Independently Modular

Run Independently Corporate Identity

Technology Agnostic Smooth User Interface

Fast Loading

Native Support

So what other options we have ?

5/9
micro-frontend-part-two.md 8/19/2019

Server Side Includes

There is another intersting apporach we can use to achieve this, most popularly known as Edge Side Includes or
ESI

Edge Side Includes or ESI is a small markup language for edge level dynamic web content assembly.

Pass Failed

Team Ownership Fast Loading

Develop Independently Native Support

Run Independently Smooth User Interface

Technology Agnostic

Sharing Basics

Modular

Corporate Identity

6/9
micro-frontend-part-two.md 8/19/2019

Integration on Code Level

Well, this is how our existing frontend monolith is working, where we do code level integration of multiple angular
modules into a final SPA build.

Pass Failed

Team Ownership Fast Loading

Develop Independently Technology Agnostic

Native Support Run Independently

Smooth User Interface

Sharing Basics

Modular

Corporate Identity

Obviously, we have some workarounds which could help but this approach also fails to be sustianable in the long
run.

Lets change the perspective a bit, and think outside the box

7/9
micro-frontend-part-two.md 8/19/2019

App Shell
There is a good intro about this approach here , which should set the context about this concept.

The app "shell" is the minimal HTML, CSS and JavaScript required to power the user interface and when
cached offline can ensure instant, reliably good performance to users on repeat visits. This means the
application shell is not loaded from the network every time the user visits. Only the necessary content is
needed from the network.

This approach lends ability to instantly load our application shell on first visit and the minimal amount of static
resources required is cahced on browser.

Now, we can lazy load independent single page applications knowns as micro frontends into our shell as per
user demand or intent.

We can do this by providing routing information for each micro frontend.

Followed by providing manifest json for each micro-frontend.

8/9
micro-frontend-part-two.md 8/19/2019

Once, we have loaded all the necessary resources for the application we can initialize the micro-frontend
application in following way

If we evaluate this apporach on our test cases

Pass Challenges

Team Ownership Modular

Develop Independently Technology Agnostic

Native Support Sharing Basics

Smooth User Interface Run Independently

Super Fast Loading

Corporate Identity

With this, App shell felt like most appropriate approach to solving our frontend problem.

Engine is designed from ground up to to leverage Application Shell architecture, We achieve this by incorporating
Design Pattern known as Inversion Of Control or IOC containers on Browser and Nodejs layer, which help are
applications to do Dependency Injection instead of doing direct source-code imports, this pattern helps us to
build applications that provide low coupling and high cohesion.

Hence with UI Engine, developers can build their micro frontends and each application can be coupled with a
server part that provides view level RESTful APIs or exposes certain downstream services via API gateways that
power applications registered in App Shell.

9/9