Micro frontends

Micro Frontends
Why do we need Micro Frontends?

www.technovature.com
UX Development
We Love it.

Fast Evolving
Full Stack Environments
SOA/Modular -> Microservices
Agile Integrations
Cloud Development
HTML5/Bootstrap
Angular/JS based frameworks
Frontend Modular
Development ?
Reusable Components
HTTP/Load Balancer

Key Questions.
• Does your services represents different business
cases/domains..?

• Does the services needs to be deployed and managed
independently..?

• Does different parts of the application has different
scaling/Technology needs..? 
• Has your existing system grown so large in size and
complexity that Innovation and freedom of
development is stifled?

–Melvin Edward Conway.
“Organizations which design systems are
constrained to produce designs which are copies of
the communication structures of these
organizations.”

–Martin Fowler
“ Don’t even consider microservices unless you
have a system that’s too complex to manage as a
monolith. The majority of software systems should
be built as a single monolithic application. Do pay
attention to good modularity within that monolith,
but don’t try to separate it into separate services.
However….a bit controversial statement from Martin below…

–Adrian Cockroft
“A loosely coupled service oriented architecture
with bounded contexts to make sure you break
your problem into the right chunks”
“An approach to developing a single application as
a suite of small services, each running in its own
process and communicating with lightweight
mechanisms”
–Martin Fowler
What are Microservices?

Microservices Approach

Key Benefits
Separate components – The Primary benefit of the microservice architecture is its
loosely coupled components. These components can easily be developed, replaced and
scaled individually.
Increased availability and resilience – Microservices improve fault isolation. As complex
applications are broken into separate service components and deployed on multiple
servers, failing of one of the services or modules will not impact the entire application. A
single service fault can easily be replaced with another service (simple to build resilience
around the small set of services) increasing the application’s availability.
Easy to change technology stack – With microservices, software development teams
can try a new stack on specific service to avail larger benefits at the application level.
There is no long-term commitment to one particular stack as there are no dependency
concerns.
Easy to understand even in distributed environment – In a distributed development
project when some of the team members are geographically dispersed, microservice
architecture make it easier for dev teams to understand the entire functionality of a
service as it is not built into one single package.

Key Beneﬁts
Organized around business capabilities – Microservices are not organized around
technical capabilities of a particular product, but rather business capabilities.
Re-usability of services – As microservices are organized around business
capabilities and not a speciﬁc project or product requirement, they are project
agnostic. This enables technology teams to reuse services and reduce costs.
Decentralized data management – Large scale and complex enterprise
applications are normally three-tier. Martin Fowler, in his microservices article,
describes that microservices let each service manage its own database, either
different instances of the same database technology or entirely different database
systems. As he mentioned, this approach is called Polyglot Persistence.
Easy to Deploy – While technology teams have to deploy an entire application
again because of small change in the code, with microservices this deployment
becomes easy. The scope of deployment is smaller and only the service that has a
problem needs to be deployed again.

Web Frontend ?
• So what about the Frontend/
UI?

• Do we have something similar
to Microservices for
managing Web UI/Frontend?

Frontend Challenges
Developing modern frontend isn’t easy. Following aspects are involved:

• Classical SOA-style data integration, often done by a dedicated service, called Backend
for Frontends or Edge Service.

• Managing frontend dependencies (JS, CSS, etc.) required by various HTML fragments.

• Allowing interactions between HTML fragments served by different services.

• Consistent way of measuring users’ activities (traffic analytics).

• Content customization.

• Providing tools for A/B testing.

• Handling errors and slow responses from backend services. (APIs)

• There are many front-end devices: web browser, mobile… Smart TV and PlayStation®
are waiting in the queue.

• Offering excellent UX to all users (omnichannel).

The last two things are most important and most challenging. This means that your front-
end applications should be consistent, well integrated and smooth. Even if they shouldn’t
necessarily be monolithic they should look like a monolith. This lays down the case for a
Micro Frontend.

Web App
Team A Team B
CUSTOMER
APIS ARE USED BY A FRONTEND MONOLITH
Source: Zalando
• Classical SOA-style data integration,
often done by a dedicated service,
called Backend for Frontends or
Edge Service.

WEBAPP GETS CONTRIBUTIONS FROM MULTIPLE TEAMS
WEBAPP
Team A Team B
• Managing frontend dependencies
(JS, CSS, etc.) required by various
HTML fragments.
• Allowing interactions
between HTML
fragments served by
diﬀerent services.

Micro Frontend Approach

–UI Guru
“The term Micro Frontends is a derivative of the
micro services approach. It represents the
architectural approach for the composition of
multiple self contained and loosely coupled UI
components (services), where each component is
responsible for a speciﬁc UI element and / or
functionality.”

TEAM A TEAM B
Source: Zalando
TEAMS OWN FRAGMENTS

TYPICAL MICRO-SERVICES LAYER
Team A Team B
FRAGMENTS USE THE BACKEND API
Source: Zalando

TEAM A TEAM B
LAYOUT
SERVICE T E M P L AT E S
ROUTER
R O U T E S
C U S TO M E R
A P I C A L L S
ASSEMBLED CONTENT IS STREAMED TO THE CLIENT
Source: Zalando

TEAM A TEAM B
TA ILOR
T E M P L AT E S ( Q U I LT )
S K I P P ER
R O U T E S ( I N N K E E P E R )
C U S TO M E R
A P I C A L L S
MOSAIC COMPONENTS
Source: Zalando

C U S TO M E R
Path = /api/cart
01101
001110
10100
101110
101110
11
Path = /*
Path = /products/*.html
J I M M YSKIPPER

TA ILOR
ROUTING
Source: Zalando

c a t a l o g : P a t h ( " / * c a t e g o r y " ) - > " h 4 p s : / / c a t a l o g . e x a m p l e . o r g " ;
p r o d u c t P a g e :
u s e r A c c o u n t :
/ / 4 0 4
P a t h ( " / p r o d u c t s / : i d " ) - > " h 4 p s : / / p r o d u c t s . e x a m p l e . o r g " ;
P a t h ( " / u s e r / : i d / * u s e r p a g e " ) - > " h 4 p s : / / u s e r s . e x a m p l e . o r g " ;
n o t f o u n d : * - >
m o d P a t h ( / . + / ,
< s h u n t >
" / n o t f o u n d . h t m l " ) - > s t a t i c ( " / " , " / v a r / w w w " ) - >
A domain-specific language (DSL) for describing Skipper route expressions, route definitions
and complete routing tables.
Route = n Predicates + m Filters + 1 backend
ESKIP ROUTING DEFINITION LANGUAGE

One or more conditions. An incoming request must fulfil each of them to match.
Many built in predicates for pretty much everything around HTTP requests.
P a t h R e g e x p ( / r e g u l a r - e x p r e s s i o n / )
M e t h o d ( " H E A D " )
H e a d e r ( " A c c e p t " , “ a p p l i c a t i o n / j s o n " )
A n y ( )
Skipper is easily extendable with custom predicates
P a t h ( " / a p i / * r e s o u r c e " ) && H e a d e r ( " A c c e p t " , " a p p l i c a t i o n / j s o n " )
PREDICATES
Source: Zalando

Filters are used to augment the incoming requests and the outgoing responses, or do other
useful or fun stuff.
A lot of built in filters give a lot of powerful features
s t a t i c ( " / i m a g e s " , " / v a r / w w w / i m a g e s " )
s t a t u s ( 4 1 8 )
r e d i r e c t T o ( 3 0 2 , “ h = p s : / / u i . e x a m p l e . o r g " )
d r o p R e q u e s t H e a d e r ( “ h e a d e r - n a m e " )
ﬂ o w I d ( " r e u s e " , 6 4 )
Skipper is easily extendable with custom filters
s e t R e s p o n s e H e a d e r ( " m a x - a g e " , " 8 6 4 0 0 " ) - > s t a t i c ( " / " , " / v a r / w w w / p u b l i c " )
FILTERS

• API Gateway
• Split mobile and desktop traffic
Split traffic based on version header•
• OAuth authentication reverse proxy
•
In front of a third-party service that doesn’t support OAuth
Redirect unauthenticated requests to other endpoint•
• Weighted traffic control
•
Use the same route with different endpoints
Stickiness via cookies•
• HTTP file server
HTTP compression proxy
Custom predicates + custom filters = you name it
•
•
FLEXIBLE AND OPEN FOR INDIVIDUAL CREATIVITY
Source: Zalando

• Fragments are regular HTTP endpoints
• Fragments respond with HTML fragments (no <head>/
<body>) Communication based in HTTP Headers
• No custom/complex protocol
FRAGMENTS
Source: Zalando

TAILOR
• Tailor is a layout service that uses
streams to compose a web page from
fragment services.
• Loads content of all fragments
from the template in parallel
• Initialises fragments client-side code
• Offers nice error handling and
fallback features with circuit
breakers
• Written in Node, Tailor is a library that
provides a middleware which you can
integrate into any Node.js server.

Project Mosaic
Microservices for the frontend
• Mosaic is a set of services, libraries together with a
specification that defines how its components
interact with each other, to support a microservice
style architecture for large scale websites.

• While decomposing the backend into microservices
is a widely adopted approach to achieve flexibility in
development and operation, most frontend solutions
are still running as a monolithic application.

• Mosaic addresses this issue by using Fragments that
are served by separate services and are composed
together at runtime according to template definitions

Skipper
Shaker
Tailor is a layout service that brings microservices to
the frontend by composing a website out of various
Fragments (such as Header, Product, and Footer).
Quilt is the template storage used by Tailor.
It integrates with Zalando's team structure
and provides a REST API that allows
multiple development teams to manage
their templates.
Innkeeper is a RESTful API that stores routes,
so that they can be fetched by Skipper.
Innkeeper can export the routes in the eskip
format. As routes are divided by paths, it allows
multiple teams to manage their individual
paths. It is developed in Scala.
Tessellate is a server-side React renderer
that creates static HTML and a
complementary component tree from
abstract JSON deﬁnitions. It comprises
several micro services built on top of the
Mosaic architecture.
Shaker is a library and living showcase
for UI components. It is used inside
Zalando to provide a consistent user
experience while developing Fragments
in distributed and autonomous teams.
Skipper is an extendable HTTP
router for service composition. It's
built on top a reverse proxy with the
ability to select routes based on
predicates, and to modify requests
and responses with ﬁlters.

-  runtime injection of new features
-  faster feedback loops
-  tech agnostic
-  end-to-end responsibility
-  full control
-  lean, agile processes
-  independent development
-  continuous delivery
GROWTH
-  faster onboarding
-  magnetic
-  easy to spin-off new teams
PRODUCTIVITY
INNOVATION
RESULT
Source: Zalando

Degree of
Independence
Code
Organization
Full Stack
Selection
Team
Organization
• Each Service is
independent with its own
component(s) now.
• You can choose to share
some components
• Expanded choice in Front-
End Design with your
choice of Tools for each
Micro Frontend
• You no longer bother to
connect a complex
monolith web frontend
with a multitude of
backend APIs.
• You connect a specific
Micro Frontend Fragment
with a designate backend
API.
• A shared codebase in pure
JavaScript e.g. managing
routing and user sessions.
Also some shared CSS.
Both should be as thin as
possible.
• A collection of separate
modules, “mini-apps”,
built in various
frameworks. Stored in
different code
repositories.
• A deployment system
that bundles all the
modules together from
different repositories and
deploys to a server,
whenever a module is
updated.
• A decision to chose a full-
stack has to be made for
every microservice.
• Choose wisely as too
much of choice can create
problems related to rigid
talent needs.
• Managing expanded
knowledge base of
polyglot frameworks
becomes difficult. How do
we solve that?
• Team members
specializing in one stack
cannot move to another
one with ease. How do we
create cross-skills teams?
• An independent, self-
contained team should
work on each
microservice.
• Please note most of the
skills you require here are
front-end specific.
• Designers followed by
Web Frontend specialists
can follow the Full-Stack
choices made already
here.
• Adapt your Agile Planning,
Management and Tracking
accordingly
• Identify Your DevOps
Teams
What’s Next?
Continuous Delivery Organization

Microservices -
Backend and
Frontend
Consultancy. We
design a Custom
Roadmap with a
matching set
solution for a proper
migration to a Multi-
Stack Microservices
Multi-Tiered
Architecture.
Microservices
design and
development using
the most optimal
multi-stack, polyglot
programming
environment that
draws from the best
in the Industry.
Microservices
Migration planning
and a project
execution taking into
consideration your
current custom
application
architecture and
migrating you to a
best in class
microservices
architecture.
Microservices
containerization,
deployment model
using the best Agile
DevOps models that
exist today and
deploys to various
cloud platform
models with ease
and the highest
speed to production.
At Technovature, we take pride in oﬀering the below Microservices related services & consultancy.

CONTACT:
sales@technovature.com
YOUR PREFERRED MICROSERVICES
FRONTEND DEVELOPMENT PARTNER

Thank You
E-mail: sales@technovature.com

Micro frontends

Micro frontends

Recomendados

Más contenido relacionado

Último

Último(20)

Destacado

Destacado(20)

Micro frontends