This discussion centers on the evolution and practical application of micro frontends, highlighting their benefits for large organizations, common pitfalls, and future directions influenced by AI, as presented by Luca Mezzalira, author of the industry-standard book on the topic.
Mind Map
Genişletmek için tıkla
Tam etkileşimli Mind Map'i keşfetmek için tıkla
Hello, good evening, and bona sera.
Today, I'm sitting together with Luca
Mezzalira, and we will talk about micro
frontends and his second edition, his
brand new second edition of his book on
this topic. Hi, Luca.
Hi, Manfred. How are you doing?
Cannot complain, and you?
Yeah, all good. All good.
I can't wait, honestly, to have this
discussion with you because, honestly, I
I highly respect you in in the technical
side, and I think we are going to have
like a a nice chat together about micro frontends.
frontends.
Awesome. Awesome.
Yeah, so I I just mentioned before when
we chatted a bit, your book is somehow
the industry standard for micro
frontends, and I think it's one of those
books. Not many people achieve this, but
it's one of the books that will be
relevant even in years, perhaps in
decades, because, yeah, it describes
everything that nicely in a way that is
everlasting. It's a How do you call it?
A evergreen topic, isn't it?
Thank you very much, Manfred.
To be honest with you, I was surprised
as well about the success of the book,
especially the first edition.
When I spoke with the Riley, they were
telling me that they had the
a very interesting pattern of my book,
and why they asked me to to write the
second one
because they they started to see, let's say,
say,
good, let's say, amount of people that
were interested at the beginning, but
then it started to ramp up even further
2 3 years after the book were released. And
And
because of that, they told me, "Listen,
do you have something new to say on
micro frontends?" >> [laughter]
>> [laughter]
>> Listen, I got like the basically brand
new book, and hence why I spent like the
last 18 months, 20 months writing the
new book, and then it was released in
November, if I remember correctly, 2025.
Mhm. Mhm. >> [clears throat]
>> [clears throat] >> Cool.
>> Cool.
So, it seems like you have been an early
adopter, and perhaps that's why people
slowly started buying it more and more
over the years.
Yeah, correct. I think there was a boom
of micro frontends
implementation and penetration in
companies, especially enterprise customers,
customers,
probably around 2020,
2020,
2022, more or less.
Two years, basically, I started to see a
surge of requests around micro frontends,
frontends,
especially because
I believe
people start to understand that that
they they struggle a lot on the delivery
side. They moved many enterprises when
they have like, I don't know, 50, 100,
or more developers, they had like a
clear pattern on the backend leveraging
microservices, while on on the frontend,
they didn't have, let's say, too many
options apart from trying to be as
polished as possible in their code base,
but we both know that in the long run,
when you have, let's say, multiple
people that don't have, let's say, clear
ownership, and they jump from different
areas of the applications, that they
need to have a lot of cognitive load
that is thrown at them because they need
to understand every single line of code
in large application. That is not
sustainable, and it doesn't result in
something that is,
let's say, easy to maintain. And
therefore, this idea of
leveraging the principle of
microservices, splitting up an
application into modular chunks that can
be deployable independently and owned by
a single team,
it started to have a lot of legs.
Despite the JavaScript community at the
beginning was a bit skeptical
when I started to pitch certain ideas
behind that, but obviously, distributed
systems are by far different from
monolithic ones.
Yeah, yeah, totally.
Suddenly, you have to embrace pattern
you did not need before, perhaps pattern
that have been considered an
anti-pattern before.
And it might also increase the
complexity if you use it and don't need
it. Have you also seen such situations
where people used it while they did not
Yeah, unfortunately, it's quite common,
right? Because
the thing is
we live sometimes with hype, and
the main problem with micro frontends is
that they can become
very complicated very quickly if you
don't know how to tackle them. So, if
you treat them like like components,
obviously, you are already
a step closer to fail miserably your
migration to micro frontends, and that's
I probably, I would say, is the main
problem that I've seen in the last
I would [snorts] say, decade with micro
frontends when they went too granular
too fast,
and you don't create the governance
around, you don't provide, let's say, decent
decent well
well
decent time on invested into into the
design in the system that I think is the
most important things. And to be frank,
it's not only for micro frontends, it's
for any system out there. If you even
with microservices, if you just rush to
create the nano services, you're going
to have a very tangled system in no
time, and that's the the challenge or
the drawback of distributed systems.
Mhm. Mhm. >> [clears throat]
>> [clears throat]
>> So, how did you become an early adopter
on this topic? I think you already did
it before it was
a hype, a fashion.
Way before. So, I started to even before
the the name micro frontends, because,
by the way, this is the
10th anniversary of the the name micro
frontends that came out in 2016. So, as
you can imagine, super excited, but I
started in 2015 thinking about
how can overcome a specific problem in
the company I was working for that was
is called the Zone. This is a live
sports streaming platform. The problem
we had is that we needed to handle
roughly 30, 40 different devices, like
living room devices specifically, and
set-top boxes,
for, let's say, quick update of the
application. And
some of them were quite controversial
because you can Not every single device
has an app store like you have on
mobile. And even then, if you have the
app store, it doesn't mean that the
penetration of a new version could,
let's say, be immediate.
So, what what happened back in the days,
they they asked me to figure out a
solution that will enable us to avoid
the common issue of
certain set-top boxes that have a lot of
penetration inside the market, but they
are quite old, where I can only update
my application flashing the firmware two
or three or four times per year. So, as
you can imagine, in the life cycle of an
application, deploying four three, four
times per year is not ideal. So, the four
four
that I've seen later on also applied to
from Netflix, we had this idea of
decoupling, basically, the container of
the application by the application
itself. That back in the days, we were
doing exactly the same thing on my
in another company I worked for on
gambling and for mobile application. And
even when I was a flash developer, one
of the technique for making the
application extremely responsive and and
light was creating an empty movie clip
that basically enables you to lazy load
a Swift file inside the flash
application. That enabled me to work
also on embedded system with flash,
despite people were saying flash was
rubbish and performance-wise wasn't
working properly. But I run inside a
Centrino board, the first Centrino board
we had in Europe, dual core Intel, where
we put inside a Ducati motorbike, and we
basically powered the dashboard of of
the motorbike with a Gen 2
application engine 2 operating system
that was running at a C daemon that
retrieving the data from the,
let's say, motorbike, like the the
engine directly. So, the speed, RPM,
etc., and we were basically displaying
with intense of milliseconds directly on
the the display that we we were using.
It was like fantastic project, but in
general, the idea was coming from that.
And worked pretty well on on mobile on
TV devices as well because,
first of all, we have seen a boost of
performance straight away because we
watch we were just loading the
JavaScript was needed compared to the
single page application we had at the
beginning. Also, because on on
um let's say, living room devices, you
have to bear in mind are are low-end
devices. There are, let's say, for
instance, an iPhone 12 probably
has more power than any other set-top
box out there
without taking into account, obviously,
Apple TV or specific Android TV
application where the the hardware is
really really good. So, for me, starting
with this idea of lazy loading
applications and then trying to
understand how to split them was
mandatory back in the days, and
made a huge impact in the industry
because when in 2017, I started to
preach this idea of we have done this,
and this is how we have done it. I
remember the first conference I I did
like a talk of 40 minutes in Ireland,
and then I spent roughly 5 hours
answering questions outside the stage.
And and that happened again in in Amsterdam
Amsterdam
with a colleague of mine where we
delivered similar talk. And
the thing that people didn't understand
how was possible and how to do that
because, again, it wasn't a
framework-based approach. It was an
architecture design approach that I was
quite familiar with because in the past,
I I I designed a lot of architectures
for frontend, but not only. And
therefore, for me, it was like
day-to-day, but I understand very
quickly that for many people
it was, let's say, out of their comfort
zone because they were used to do,
especially in JavaScript, taking a
framework and leaning towards the best
practices provided by the framework
itself. While in this case, we need to
detach from the framework itself and
start to think holistically, how can I
create a system that, let's say, improve
our organization? Because at the end of
the day, any distributed system is not
only for the users out there that will
have some benefits, but majority of the
time is for the organization itself that
will be able to ship faster and to have,
let's say, clear boundaries, clear
boundaries and ownership across teams.
That is not
a simple task at the beginning.
Mhm. What I really like here is that
this entire idea
was driven by business needs, like
bringing the zone to a lot of different
environments and splitting it according
to different parts in the organization.
Um another aspect that has to do with
this or that looks at this point of the
world is domain-driven design, something
you also mentioned in your book. So, how
does those two topics come together?
Front-ends on the one side, micro
front-ends and domain-driven design on
the other side. So,
So,
back in the days, I was responsible for
uh let's say thinking about the
evolution of the system because we were
growing very fast
and we moved from more or less 50 people
across the entire organization to 3,500
in a matter of let's say months, like a
year and a half, 2 years max. Uh because
we started to put more emphasis into the
system. We started to grow from tens of
thousands of users to millions of users
and and obviously required a completely
different mindset on how to structure ourselves.
ourselves.
The it was crystal and clear we were
starting to onboard a lot of teams
inside the company. In fact, the tech
department was composed by 550 people.
Uh that is not a small uh tech
department if you think that we are in
Europe and not in US, spread across,
let's say, four different cities.
And therefore, for me, you know, I had
to figure out how can I make it work
across with all these, let's say, um
um
in this specific situation, social
technical situation. And the only thing
I was thinking of was, okay, on back-end
I have the I have an a plan. It's called microservices.
microservices.
Um I didn't apply it at scale before,
but for me it was crystal and clear that
that was the only way
I could enable multiple teams writing
the back-end and deploying
independently, fails gracefully, scale
independently, and so on. And and
therefore, we went in that direction.
But from front-end, I had the problem
that I have equally as many front-end teams
teams
that has to ship a lot of stuff and in
multiple devices. And some devices I can
share some code, some others I cannot.
And therefore, my idea was, okay, let's
start from
let's take the the principle that we
usually I use when I design
microservices. Therefore, I starting
from the domain-driven design,
looking into, okay, strategic
domain-driven design specifically more
than tactically. So, because the
strategic one enables you to look here
take a step back, look holistically on
the system in on the business
side. And I started to look into the
capabilities that we have and slowly but
sadly, I recognized some subdomains that
were kind of clear inside the system.
And then I I layer up basically the
subdomains that I identified on the paper
paper
with the data points that I retrieve
from Google Analytics and see how our
users were interacting with with the
platform. What turns out that
very quickly I can I could see, let's
say, some patterns that were quite clear
for us.
On the back-end, obviously, they were
had to, let's say, be more granular
because we have by far more teams on
that side. And we had to split, by the
way, not in cross-functional teams as I
I wished at the beginning, so having
front-end back-end together, but in
front-end teams and back-end teams
because the amount of programming
languages that we have to build would
force us to have, I don't know, 14
people per team if we wanted to to
develop a specific feature across all
the devices. Because we were using
Swift, we were using
Java for the
the
Kotlin specifically for for the Android
applications. We were using for web
React and MobX. As for some TVs, we were using
using
React and MobX as well. Some others we
were using custom languages dedicated
for that. So, it was fairly complicated
scenario. Therefore, we couldn't afford
to have, let's say, a single team to
write JavaScript for everything
otherwise the performance will be
jeopardized. We even have two teams
dedicated to the video players because
the video players were extremely
complicated. Even we we evaluated that
you have no idea how many, but the
the complexity is that at the end we
ended up building our own live streaming
video player because all the ones
available, even open source, weren't
reaching the level we wanted.
But going back into the
the the how to split the application,
for me it was crystal and clear that
there were some patterns very that the
were mapping in a more coarse-grained
fashion compared to the back-end into
the front-end. So, we had like a lot of
landing pages, pages, a lot of traffic there,
there,
millions of of visits
per per day
back in the days, where basically I had
to create a custom
let's say implementation, so using ISR,
so I can
render at build time everything stored
inside the CDN, forget about it, and I
know that that million of requests won't
hit origin or wouldn't would not affect
all my APIs because they are very well
stored with all the data already
available into the CDN. Later on,
if you there was a split after the
landing page. Either you are an existing
user or a non-existing user. If you were
an existing user that you have already
access to the platform, the landing page
was skipped straight away. So, you went
you went straight to the catalog. That
means basically you save a lot of
kilobytes of JavaScript wasn't loaded
because weren't loaded because you
basically [snorts] don't have all the
payment SDK integrated, you didn't have
all the landing page, all the logic for
signing sign up, all the different
integration we had at that stage. So,
you basically load the catalog and you
load the the video player. That was it.
You didn't because at the end of the
day, the rest of the system wasn't
needed as much as
the catalog when you were
let's say an existing user. Uh
obviously, you could also navigate into
the my account page, but I basically
count like probably a single-digit
amount of user that were going there, so
I splitted them up in different micro
front-end. And then, if you weren't
an authenticated user, you were a new
user or an existing user that was moving
in another device, in that case, I
basically started to map the the
onboarding journey where you have sign
in sign up at the beginning together.
But slowly but sadly, when we started to
roll out new countries,
it turned out that it wasn't it was
impossible to keep the cognitive load of
all the different payment methods for
for new users and in new countries
because every country has its own let's
say set of payment methods based on the
partnership that we had. And therefore,
we split them up into two teams, one
dedicated on sign in only,
retrieve email, retrieve password, and
the other one dedicated on on payments
only. And the beauty of that is the is
the leveraging domain-driven design, I
could map and design things on how the
back-end was communicating together
using synchronous and asynchronous
programming on the back-end. And at the
same time,
on the front-end, I was able to map a
single micro micro front-end to a set of
microservices. So, therefore, my design
became, let's say, very modular with the
a coarse-grained granularity. We didn't
go straight like the classic um mistake
that I've seen very often with with
teams is, oh, we treat micro front-ends
as components at that level of
granularity. That failed miserably very
often because you are you are basically
let's say confusing a component with a
micro front-end, where in in a component,
component,
the domain is owned by the container of
the component.
If you think about the button or if you
think about, let's say, a carousel,
whatever it is, those components are
basically providing
let's say an easy way to integrate a
specific feature that is consistent
across the entire application. So, what
you are basically building them is for
reusability. While for for a micro
front-end, instead, we want to leverage
the capability of independence deploy
independent deployment and reducing the
complexity for for teams that are completely
completely
or almost completely independent for
deploying new version. Therefore, we
cannot leverage the same approach. We
need to be more coarse-grained and
encapsulate the business logic inside
that. If you start to think in this way,
now suddenly, the
having coarse-grained
sorry, fine-grained
components that are lazy loaded
create, let's say, a complexity that
basically makes
impossible to maintain over over long
term. So, what I usually do with every
single team that starts with micro
front-end, I start to to use what I call
the the vertical split. So, I take one
page or group of pages and assign to
specific team. We can always tweak them
and split them further or aggregate
later on. It doesn't really matter at
the beginning if if
let's say you find the perfect
boundaries. The important thing is is
that you start to move towards this
paradigm and you start to learn how it
works. And that for us in the zone was
was the first thing we started with for
instance with the catalog and then we
moved into the landing page and then
signing up and then all the rest. And
slowly but steadily we were
deploying the new micro front end when
we we had the possibility
and the the micro front end was ready. I
At the beginning was living alongside the
the
let's say the application that exists
the existing monolith application and
then slowly but steadily we were
migrating towards the new
approach. But remember back in the days
10 years ago we didn't have let's say a
book, we didn't have let's say
reference. It was literally a lot of
banging our head in on the wall and
trial and errors and trying to figure
out what made the most sense. For me it
was a very interesting challenge because
I had to take basically the principle of
microservices and then tweak them
towards front end in a way that makes
sense for front end. And therefore it
take it took like a while before we
reached let's say the the right
trade-off for making that working across
the all the different devices that we
were supporting. >> [clears throat]
>> [clears throat]
>> Yeah, you really speak from the heart.
One thing I really find interesting here
is that you at least say it between the
lines that achieving a perfect slicing
is really hard and perhaps there is not
even a perfect slicing. So you somehow
need to get going and then you need to
adjust your path on the go.
Absolutely. The
the challenge overall in in boundaries
and that is not only for micro front
ends is in general for for everything
even if even if you think about in a
monolith you want to define the
boundaries for a module. How coarse
grain or fine grain should it be? So
it's not let's say an easy approach.
Uh therefore
for me you know it's it's an iterative
approach where boundaries is the only
thing that
you there are some heuristics that I use
nowadays for identifying them in in a
simpler way. One for instance is
rate of change is an important one. So
how often do I change specific module?
And I usually give this example to
explain it. So think about for instance
you are creating a payment micro front
ends, okay? Where you have let's say
multiple payment methods. But then you
realize very easily that maybe you have
like four five but there is one maybe
credit card that require more
maintenance in the long run. While the
rate of change of a PayPal SDK or any
other SDK is way lower. So potentially a
good way to to tackle that it could be
that you create instead of
let's say a very complex micro front end
that has like one one payment methods per
per
per micro front end you can have let's
say an aggregation of multiple payment
methods of for one micro front ends and
the other one is that
that is the credit card that has high
rate of change is in another micro front
ends. Why that? Because in reality the
rate of change is driving that
decision and
it's very likely that those two micro
front ends because they live inside the
same subdomains that is payment will be
owned by the same team. Therefore that
team doesn't have to coordinate with the
other teams. That's the beauty of this.
So when you start to look holistically
on on the social technical system so how
so who is owning what and how granular I
want to I want to be I can decide that
having these two micro front ends for
payment could be good or I can decide
that I want to have a single one and
obviously I will bite the bullet on
having let's say to retest every single
payment methods every time that there is
a change. So here we are just discussing
about trade-off and there is no such
thing like the optimal trade-off. It's
just every single trade-off has some
pros and some cons. And therefore if you
start to think about that
you start to see that you know there
isn't a way that I can tell you oh
Manfred you know 100 lines of code is a
micro front end or 1 million lines of
code is a micro front end. It's
impossible giving you that. But if you
have heuristics like security or you
look into the rate of change stuff like
that you start to see what should be
inside a boundary or outside a boundary
if you
if you can split it or it's better to be
more let's say coarse grain and having
collocated code there. And similarly
happens also on the back end. I have
like for instance a customer that is
working on on finance. And in finance
for instance they were telling me oh
yeah we we are dealing with with the
stock market. I said okay so you need to
reduce to the bare minimum the
communication over the network because
otherwise every single hope you are
penalized by milliseconds. And you need
to be let's say
very well aware that if you there is a
change of of stock you need to update
the the price. So therefore there the
modularization happen not at the
infrastructure level but at the code
level through creating modular modular
modular
application that has different modules.
In instead similar to micro front ends
when you think about how you are going
to let's say collocate or not the code
is an exercise on understanding how many
external dependencies you are creating.
And that basically lead very nicely on
the on the shared dependencies, right?
Because there are certain shared
dependencies that are a must have like
login libraries or design system stuff
like that. But the reality is every
everything else that is outside a couple
of different things you need to ask your
yourself like three four 10 times before
you want to externalize something like
that because you are creating external
dependency that at the beginning seems
like a smart choice. But again if you
have a high rate of change then you need
to redistribute the changes across all
the different micro front ends and
retest them. And it's not a walk in the
park because basically you are for the
vanity of creating something reusable
you ended up to create let's say a
bottleneck further down the line when
you are on the testing phase every time
that you change something is going to be
retested. So it's becoming very
complicated very quickly. That's why the
design phase of micro front ends is
extremely important.
I think this is really an important
topic and I know that a lot of people
are struggling with the question how to
slice it. So you just gave us two
heuristics. Let's call it heuristics.
One was different
different I think performance
requirements with the stock market and
the other one was different requirements
towards something else. What was it?
Correct. So the other one was the rate
of change of of your code. So
that that I think is is the
one of the key ones. But again it could
be security as well. So instead of let's
say applying security scattered across
multiple micro front ends maybe you want
to centralize one in one place so it
becomes easier so if I need to change I
change once for everything. So this kind
of heuristics that you will discover
sometimes before the development
sometimes after because maybe there is a
new regulation is coming in and you need
to do something about that and you can't
really just ignore it. Therefore we need
to accept the fact that boundaries are
things that are that can mutate over
time and there is no harm in saying
that. The only thing is you need to
design things first of all making sure
that you don't create external
dependencies between team because if you
find too many external dependencies then
there is no chance that micro front ends
or any distributed system will work.
Cool. And I think before you also
mentioned you looked at the customer
journey to find out how to slice it
also into analytics to find out what is
used together and so on. Yes because
that that for me was important. I had
like my
let's say context map where we had all
the different
subdomains and bounded context of my
back end part. And sometimes people
start I remember like five six years ago
there were people saying oh okay so I
have a microservice therefore I have a
micro front end. I said no there is no
need of such thing because the reality
the decoupling between the front and the
back end is still exactly the same of a
monolith. It's called API. So you have
an API that is decoupling these two
worlds and therefore you can say
perfect. So this micro front ends
consume three four five APIs from
different domains potentially. Or you
can create a back end for front end.
There are different let's say approaches
that you can have on the back end for
mitigating the aggregation of different
domains because majority of the time you
know the back end
is more complicated than the front end
not because
you know you want to over complicate the
back end but because you know if you
change something on the back end then
the front end that doesn't have to be
redeployed. You can let's say
externalize a lot of stuff on on the
front end so the back end can take over
and say okay so now there is high
traffic therefore behave in this way.
You just provide the signal and the
front end basically will behave in
different ways instead of redeploying
let's say a new version.
Yeah, I think this is also an important
learning [clears throat] that there is
not necessarily a one-to-one
relationship as you said. Yes. Between
microservices and micro front ends. So
in your case was it rather one-to-many
or was it many-to-many with a back end
for front ends in between? So
back end for front end pattern I tend to
avoid them in in terms of let's say just
saying okay use BFF because we use
somewhere else. There are specific use
cases in my opinion that uh
are great for back end and for front end.
end.
And this is basically when you want to
aggregate multiple subdomains together.
And my classic example that I
implemented in several companies is my
account. So usually in any subscription
service or e-commerce, whatever, my
account is a composition of payments,
user details, and whatever else like
orders, history, whatever it is based on
what you have. So as you can imagine,
those three elements that I just
mentioned majority of the time are
because of the complexity are owned by
different teams on the back end. So
there are let's say three domains with
different domain models. It's completely
different the way how you are you design
them and implement. On the front end
though, you want to have a single pane
of glass where you you see everything,
right? So you have a view that I can
change my payment method, I can update
my address, whatever it is. So there are
two ways in usually to handle that. One
is you use a BFF, so back end for front
end. So you basically the front end team
or the team that say the people inside
the team that are responsible for for
the front end
are owning a new layer of APIs where
they aggregate these APIs. And the
beauty of that is it is if you have
let's say not many front end developers
and you have like a complex back end, it
means that basically you design a single
micro front end that is communicating
with the BFF that is fetching the data
and sending the data to the other
domains. And the cool thing of this
approach is that you have you need like
a small amount of resources on the front
end for handling that part because the
aggregation is happening on the on the
back end on this back end for front end
layer and can be updated by the front
end team as many times as they want.
If we revert the complexity and we say
no, we want to have let's say
cross-functional teams where every team
owns his own chunk, now the complexity
start to arise because now we means that
we need to have let's say at least three
teams that has cross-functional teams
that has the
user details, payments, and
what was order history for this specific
view on top of the others that they need
to handle. And
and we need to understand how to
aggregate, how to modify all together
creating a layer of governance that when
someone is changing something won't
impact the others. So it's completely
doable, but now we're shifting the
complexity from having let's say two
three people that are handling the front
end through a back BFF and aggregated
APIs on the back end to every team is
completely independent. They ship
whatever they want, but they need to be
aware where is deployed and they need to
be aware what's happening on the other
side because if someone is changing
something, suddenly
I I might need to change my code as
well. And that's where the that's the
let's say the difference between
vertical versus horizontal split where
in the horizontal split you have
multiple micro front ends in the same
view, therefore there is a coordination
needed. not let's say as much as working
in a monolith, but in general you need
to communicate to understand, okay, I'm
changing this might impact you or not. Mhm.
Mhm. >> [clears throat]
>> [clears throat]
>> Mhm. And this exactly leads to another
topic I want to discuss with you.
Namely, there is the decision framework
you published quite early. I think it
was published even before the first
version of the book in your blog.
>> Indeed. And it gives you a lot of hold
when you doing decisions towards an
architecture for micro front ends. Can
you tell us a bit about it?
Yeah, so what I recognized in the
implementation I was making in the zone,
but as well talking with other people in
the community that there are four key
aspects that every single micro front
ends architecture required to be
designed up front before starting. So I
call them the decisions framework
because you have like these four
decisions. So one is understanding how
to split micro front ends. Is it like a
page or group of page assigned to a
team? Majority of the time I recommend
to start with that. It's easier. It's
like dealing with small single page
applications. And even on the server
side rendering works very nicely. I have
like plenty of examples of e-commerces
that are using this approach with the
vertical split on with server side
rendering. It's work like charm.
Or you can have horizontal split where
you have multiple micro front ends in
the same view. Now the complexity on the
second case is
let's say focusing on the governance,
who is owning the the who is responsible
for the the final result of of one page.
So if I have like three teams and I'm in
an e-commerce homepage, who is
responsible for that? Someone needs to
be responsible
and coordinate the other teams a bit.
And that is let's say provide maximum
flexibility. Classic example, if you
think about let's say the different
dashboard in cloud provider are probably
made with with micro front ends many of
them because they are even I remember
New Relic did let's say a talk like was
like six seven years ago talking about
how they leverage micro front ends for
the different dashboards. Because in
that case you have in your observability
tools multiple metrics that you care
about and are developed by multiple
teams. For aggregating them, they
created this let's say widget approach
leveraging micro front ends that are
basically lazy loading these metrics.
metrics.
The second part is um
how the
micro front ends are let's say routed.
So sorry, composed and then routed. So
those are I split it in these two areas
because I think it's important to
understand am I doing let's say on
client side rendering or server side
rendering. At the beginning I was
considering also edge side includes and
therefore edge rendering, but it turned
out that
the the main technique for doing that
was ESI that is edge side includes. This
is quite old markup language
that was created by Oracle and Akamai.
And and basically there wasn't supported
let's say massively by many CDNs. Only
Akamai had the full stacks and then we
have varnish that has like a bit of ESI,
but not much more than that. The
developer experience was was rubbish
compared to the rest.
And even nowadays the the real let's say
challenge of doing edge side in
composition is that in reality the data
that are living in the micro front ends
are fetched from different regions.
If you if you handling in a CDN, you
have let's say a multitude of point of
presences that are composing your front
end, but maybe one point of presence is
in Australia, but your data are in
London. And therefore you're not gaining
much on performance because of that. So the
the
at the end we we in the second edition I basically
basically
described only client side rendering or
server side rendering. And those two
have let's say quite a lot of
implication obviously because if you do
client side rendering, you have subset
of the framework that you can do and
server side rendering similarly, right?
And also scalability wise and how much
you need to think about infrastructure
completely change when when you deal
with server side rendering because
everything has to be rendered on the
server and therefore you need to find
the right tools for doing that. You need
to think about caching a different
layer, in memory CDN, etc.
While when you're moving to
the routing part is where how do you
route? There usually there are two ways
to route. There you have a global
routing that is everything that is on
the first level URL. So my site.com/catalog
site.com/catalog
first level URL usually is handled by an
application shell. So it's basically
routing the request from one version to
another one. It could be an application
shell, it could be a router happening on
the edge or a router happening on inside a
a
region in the cloud or in on premise,
but the the logic is the same. So I'm
routing basically saying hit that
cluster or load that micro front end.
That's what what I'm looking for. And
then local
routing that basically is happening
instead inside the micro front end. So
when I I select the slash catalog, the
micro front end of catalog is loaded and
it should own the let's say all the
other level of of the URL. So second
level, third level, etc. Because that
basically you are handed over to a team
or group of teams that are evolving that
part independently from the application
shell. That is an extremely important
part because you don't want to leak the
domain towards the application shell
that is another team basically involved
that will impact your release cycle. And
and the fourth decision is is the
communication. So how do you
communicate? So on horizontal split is
easy because at the end of the day you
can communicate through APIs. So maybe I
store some I don't know preferences from
from the user. So I basically use the
API to store the information
permanently. Or I can use local storage
or I can use
I don't know query strings. These kind
of things. While if I'm in a horizontal
split, the challenge is majority of the
people start with with um
a global state. And
because it it comes very natural for
front end developers. But the problem
they don't understand is that the moment
that you have a global state, it means
that you're leaking the domain out the
logic outside micro front end. Therefore
if I change something, all the others
has to be retested. And that's where the
complexity lies because now suddenly
people says, oh micro front ends are too
complex, are not worth it. But the
reality is not the micro front ends are
not worth it. It's it's the
implementation that was wrong. So
usually what you do is encapsulating the
state management inside the
inside the micro front end while you
communicate through three things, either
reactive streams, custom events, or my
favorite event emitter. And they are my
favorite for a simple reason because
reactive streams I wrote a book on
reactive programming in JavaScript and
let's say that
I think it has a lot of lags but it
wasn't at all completely embraced by the
JavaScript community in general. There
were let's say subset of the individuals
that they used also in Angular for
instance they there is an RXJS that is
out of the box that I personally love it
but obviously not everyone had the let's
say the same experience. Custom events
are bounded to the DOM
hierarchy. So if I have one micro front
end in one node that has to communicate
with a micro front end in completely
different part branch of of the the the DOM
DOM
then suddenly you need to basically find
that a DOM element that is common for
everyone that majority of the time is is
the window
object. But the problem is that you
potentially have let's say another
listener in before the the window object
that can intercept the request and
prevent to bubble up then basically
discovering the bug becomes like
impossible. While event emitter solves
all these problems because it's using
events that we are used to do with
JavaScript very easily but also is not
bounded to the DOM. You can move stuff
around without any problem is literally
just a
it is it's based on the observer not
observable but observer pattern. So
where basically what you have is just an
array every time that you say okay I
subscribe to this event you you
basically your object is added to the to
the array and then every time that
someone is saying emit I take this array
and I par- and I parse it to go through
a for cycle and say okay I emit this
event this event to this event and all
the events are passing through every
single object. Who is interested will
pick it up and react. The beauty of this
approach is that a you decouple
completely the system because it's just
an event I can test in isolation without
any problem because it's possible but
most importantly you have also the possibility
possibility
to let's say
let's say plug a a new micro front end
without let's say communicating with all
the other teams because as long as
documented what kind of events are
bubbling in a view I can easily say
perfect I'm interested on this event so
let me plug it and I will start to do
stuff with my micro front ends. It's
even for instance in if it fails and no
one is listening to to an event there is
no penalty in in the
Chrome console web console whatever is
just literally
nothing happens it's just dispatch an
event no one listen to it fine.
You don't have let's say stack overflows
or any other JavaScript error is just
literally an event.
Those are the four basically
let's say
four decisions that you need to make at
the beginning of every single micro
front ends implementation and I try that
to apply
across server side rendering client side
rendering edge side rendering and every
time those four things bubble up. So for
me that became let's say the decision framework.
framework.
Mhm. Cool.
So it's also a part of the book of course.
course.
What are the other chapters in the book about?
about?
How many you you mentioned?
No in in general what are the other
chapters of the book?
>> Oh the other chapters sorry.
So the other chapters so you have like
part of the design there is also
that is the the master chapter if I
remember well it's chapter four
that basically has a comparison of the
most used framework out there and I try
to provide
let's say and many people really like
this approach a table for first of all
obviously I describe the framework how
to implement what are the trade-offs but
then I created a table for every single
framework saying okay this one has
as a trade-off I don't know
low developer experience or a very
incredible developer experience on the
other side. On this one you know you can
work only on client side rendering on
this one you can work client side or
server side rendering. So
I try to create let's say a table for
every single framework and library out
there to provide let's say my take on on
the trade-off available.
On top of that I added the let's say a new
new
chapter on migration that is basically
talking about how to migrate what's the
mindset what how this common approach
that you should use and also I created I
updated one on CI/CD because
the automation part seems like oh yeah
that nothing changed but in reality
there are some
tips and tricks tips and tricks that
could help to let's say having a better
micro front end strategy especially
nowadays on with AI. Think about
recently we started to hear more often
harness engineering approach where you
have like basically sensor and guides
where the guides are basically skills
and markdown file or you have a bunch of
other information around okay this is my
context and I provide that in terms of
prompts or maybe rag or whatever else
you want to to provide and then you have
some some sensor that usually
is on the CI/CD side when basically the
code is generated and you start to say
okay so I want to have
I don't know the information related to
um archi- architecture fitness
functions. So I want to say this micro
front end shouldn't have any dependency
from another micro front end but only
from the shared library. This kind of
things you can implement TSR that is a
porting of of Java
arc unit from from Java
that basically enables you to describe
architecture characteristics of your
micro front end. If you run them as a
test suite
alongside your normal unit test and
integration test then you will be able
to say oh by the way this is not doable
and you can feed back through this
sensor to the LLM or to the code
assistant in order to improve that thing
and try to avoid happening again.
Similarly with static analysis if you
see that it generates code that is not
maintainable in general you want to have
let's say I don't know some limits for
instance I don't know maximum 10 lines
of code per function or you want to have
a certain cyclomatic complexity. These
kind of things can be feed back inside
your code assistant. So if you if you
have let's say at the beginning these
these guides and you implement them also
some sensors
now we have let's say a very interesting
and appealing way to let's say try to
provide as many information as possible
and guide the probabilistic system that
is the code assistant towards the result
that we expect. Mhm. Mhm.
[clears throat] Cool.
So what do you think where are micro
front ends going to? What is the future
of micro front ends? Has it something to
do with AI? Will AI influence it? Will
something else influence it or will
there be new developments in this area?
I think definitely AI will have a
massive impact on the idea of micro
front ends. I think micro front ends
fits perfectly with the idea of of of
how we think about for instance
leveraging components inside
code assistant or in general with
AI agents and and so on. So if you think
about how Claude right now enables you
to communicate with with that and then
generate code and for instance I
remember the other day I was doing a
comparison about different stocks and
I didn't even ask and he was
basically telling me oh I created a
React application for you and he
rendered inside the the page and said
say okay as you can see those are the
the differences about these two stocks
that you're thinking to invest. I said
okay that is very interesting because
now if I think about that as a micro
front end I can create a vibe code
the let's say behaviors of specific
component and then I can offer it
through MCP inside these tools that will
have a certain guidance on how they
should render specific part of the
of let's say my
I don't know application or whatever
you're you're I'm building. The other
part that I believe will have a very
interesting approach with AI is that
currently we tend to have AI that is in
the middle of the application or we
think let's say to have AI always in the
middle like as orchestrator of
everything. While instead in my let's
say test I started to think about AI as
a tool where if think for instance that
instead of having a request for rendering
rendering
server side render page instead of
asking to AI give me everything what I
really want from AI that I like the the
non-deterministic approach is the
layering or how I I I design the layout
of my
of my page. So if I'm capable to have a
bunch of micro front ends that I design
carefully in the way that I want
without any possibility to to screw them
up because I will basically use them and
then ask AI to provide me a layout and
then in server side rendering I take
basically these these micro front ends I
created the layout provided by AI and I
merge them leveraging transclusion like
we were doing in edge side include the
server side rendering etc. Then suddenly
you can have a very high dynamic website
that can be let's say completely
personalized end to end and that is provided
provided
with an experience that is unique to
either your users or to your community
[clears throat] or your users based on
how they are consuming the website
because you are feeding back the AI with
the information needed but you have full
control on how the information will look
like on the when you're rendering it.
Because chats are great but I don't know
you what you spend like I don't know
four hours chatting with with
Claude or whatever else you're using
at some point say okay why we started
that conversation why we were saying
that thing why we ended up here? Then
you start to scroll up and you don't
find anything. I strongly believe and I
started to see for instance recently on Spotify
Spotify
that I really liked this idea that the
UI should continue to have let say its
own capabilities with buttons and
everything, but behind the scene we are
leveraging AI for generating things that
are unique to the users or to the
experience that you want to propose.
Like if you go to Spotify now
you have a new rail with let's say some
prompt that you can say, "Okay, I want
to listen to music that I listen I don't
know 5, 10 years ago." And he's
basically researching inside your
history and generating a playlist on the
fly with a bunch of information
augmented by AI that makes this the
thing more interesting. So if I start to
think about how AI will impact the UI in
the future, I think there will be a
massive impact if instead handing over
everything to AI we start to aggregate
what we know that is deterministic to
what is not deterministic and we merge
all together for having the optimal
solution. And again is still trade-offs,
but the cool thing of this approach is
that you wait to weigh less on on AI
because we know that it's basically
cranking some numbers and if you operate
at scale it might be complicated. While
in this case you can potentially end up
with a small language model instead of
large language model and you are going
to have let's say a save on on
performance and cost on
on this approach because it's generating
just a tiny portion of the system that
is basically a bunch of information that
you need to put together and it can
evolve without you retraining models and
whatever. So I think this can be a good
starting point. This is what I'm
researching at the moment and I think it
has some lags from the test that I made
at the moment. Mhm.
Mhm. >> [clears throat]
>> [clears throat]
>> Awesome. Cool.
Yeah, this was a fantastic outlook. So
big thanks Luca for sharing all those
insights. Big thanks for being such a
fantastic community member
who is sharing all this stuff with us.
So it's really really
a huge thing and provides a lot of value
for people out there. So big thanks and
see you around.
See you around and thank you for having me.
me.
Videodaki o ana atlamak için herhangi bir metin veya zaman damgasına tıkla
Paylaş:
Transkriptlerin büyük çoğunluğu 5 saniyeden kısa sürede hazır
Tek Tıkla Kopyala125+ Dilİçerikte AraZaman Damgasına Atla
YouTube URL'sini Yapıştır
Tam transkripti almak için herhangi bir YouTube video bağlantısı gir
Transkript Çıkarma Formu
Transkriptlerin büyük çoğunluğu 5 saniyeden kısa sürede hazır
Chrome Uzantımızı Yükle
YouTube'dan ayrılmadan transkriptlere anında eriş. Chrome uzantımızı yükle ve izleme sayfasında tek tıkla herhangi bir videonun transkriptine ulaş.
