S10 E8 | Architecting for Autonomy: Micro Frontends & Native Federation with Manfred Steyer - The Angular Plus Show

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:08):
Welcome to the Angular plus Show. We're app developers of
all kinds share their insights and experiences. Let's get started.

Speaker 2 (00:21):
Hello, and welcome back to another episode of the Angular
Plus Show. I am one of your hosts today, Laura Newsome.
I'm happy to be here. I have with me my
one of my co hosts, Jay Jay. How's it going good?

Speaker 3 (00:35):
Uh?

Speaker 4 (00:35):
I forgot that we were doing this today, so hopefully
I'm slightly prepared.

Speaker 5 (00:39):
You'll be totally prepared. There is nothing confusing about this topic.

Speaker 4 (00:43):
So about.

Speaker 2 (00:48):
And I was that with me Yan Yan, How's it
going great?

Speaker 3 (00:51):
Fantastic?

Speaker 2 (00:52):
Jean really likes it if you ping him a whole
bunch of times. So if you have a contact information
for Yon, just make sure and just send him message
just constantly.

Speaker 3 (01:01):
Like on all platforms in LinkedIn email, fat.

Speaker 2 (01:07):
Like if you can somehow like send a message to
his kids to get his kids to be like.

Speaker 3 (01:13):
Join the podcast.

Speaker 5 (01:16):
Children's sound that's not creepy. Well.

Speaker 2 (01:18):
I am very delighted to have our guests on today.
If you've spent any time in the ang Yelo community,
I'm sure you know our guest. If you do not,
I am excited to introduce Manfred Stier, How are you today, Manfred?

Speaker 6 (01:31):
I'm fine. Thanks for having me.

Speaker 2 (01:33):
Absolutely, you know, we wanted to do a top and
the topic today in case any of you are wondering
about this. Very clear, super straightforward topic is module federation
and Native federation.

Speaker 5 (01:44):
So we're talking micro front ends.

Speaker 4 (01:46):
What's that talk about it than Manford exactly like we should.

Speaker 2 (01:52):
We should really ask Manfred to come on. So Manfred
for the audience, do you want to go ahead and
introduce yourself.

Speaker 6 (01:58):
Yeah, sure, I am Manfred Manfred Schtaya and I do
trainings and consulting and reviews for angolar people, so I
have companies doing Angola for the enterprise. And besides this,
I'm speaking at a lot of conferences. I really enjoyed
is sharing my knowledge and also writing block contiguis and

(02:24):
so on.

Speaker 5 (02:25):
Excellent.

Speaker 2 (02:25):
Yeah, and I know you've been very helpful. I personally
asked asked you questions that you've helped me out with.
I know pretty much everyone in the community at this
point has relied on the knowledge that you've shared with
the community, and so it's very much appreciated. And on
the topic of model federation, I use Native Federation every

(02:47):
day at work.

Speaker 7 (02:48):
So oh, so I'm really glad to be here because
we have questions.

Speaker 6 (02:58):
Yeah, it's not an easy topic, so it can be dampting,
but it's it's not a free.

Speaker 5 (03:04):
Lunch, right right.

Speaker 2 (03:05):
So before we really dive into the topic, so model
federation and native federation don't make any sense without the
whole idea of microphone and architecture. So do you want
to for the listeners who are not familiar with microphone ends,
do you want to give a brief description of what
that means?

Speaker 6 (03:24):
Yeah? Sure. So the idea is that somehow, if you
have a huge system, we need to cut it into pieces.
To slice it into pieces, and ideally we want to
have pieces that don't know much about each other so
that they can change something here without breaking something there.

(03:45):
And if you have several teams, ideally each team would
be responsible for just one slice or a tiny amount
of slices so that they can do their own stuff
and don't need to coordinate that much. So it's a
lot about team autonomy. And you can achieve this in
several ways, and each and every way has their own

(04:08):
advantages and disadvantages. For instance, you can structure a huge
application internally into modules or libraries or folders and access
some nice possibilities to make sure that this source code
cannot access that source code. But if you want to
maximize the team autonomy, then you have several applications so

(04:33):
called microfroundance, one application per bart per vertically slides, and
then that challenges somehow. You need to bring everything together
because the user wants to have one entire thing they
can work with. That means we need to integrate those
solutions that are separately developed and deployed at runtime. We

(04:56):
need to do this at runtime because everything happens separate
and those parts only meet at rundime for the first time.
And yeah, for this microfront and technologies are attempting solution.
And one of those technologies is module and or native federation.

Speaker 2 (05:17):
So what is the underlying difference between module Federation and
native federation.

Speaker 6 (05:21):
Originally Module Federation came with web back five and for
me it was really an eye opener because already in
the better phase, I have seen this is solving so
many issues all my customers have. Okay, not all of them,
but a lot of them have, especially when they want

(05:41):
to verticalize everything into separate applications. Basically, it allows us
to load something from over there, from a different application
that has not been known at compile time, and it
can be done in a way that is more or
less agnostic. Do your framework like Angola, So for Angola

(06:04):
it looks like lazy loading, but underneath the covers, this
module federation thing is scrapping over and taking something from
a different application. And it also allows us to share dependencies.
If we have the same version of Angola here and there,
we can just share it. So this arrived with batback five. Meanwhile,

(06:27):
we know that that back is not a big thing anymore.
All the communities are moving to other bundlers because meanwhile
we have better solutions. While bab back five years ago
was the go tool solution for each and every community,
meanwhile we have better solutions in terms of performance. And

(06:51):
when I saw that also the Angler team is moving
to other bundlers, I got a bit afraid because I
saw on the one side, module federation in that back
is exactly what we need, and on the other side,
I was afraid that we cannot board it to each
end every other bundler, especially because we need to be

(07:13):
future proof in the long term. If we have such
a huge system. Usually this system is developed for ten years,
fifteen years, twenty years. We cannot foresee what will happen there,
and soon we need to have a solution that works
with everything, even with stuff we don't know today. And
that's why I reimplemented the idea of module federation. Let's

(07:37):
say the mandal model in a neutral way, in a
technology agnostic way, that is just a wrapper around each
and every possible bundler. In theory, you could wrap an
ex copy command with it. Don't do it, but if
you want to create your bundles with x copy, feel
free and you can use native federation. In addition, and

(08:00):
besides this, it's also using web standards like inboard maps
and ekmask rep modules. And if we put this together,
being not depended on a bundler and using web standards,
then this is a solution that is very bodible and
can help us in the long term. So what ability

(08:22):
was the key here? And so nowadays we can use
the Angler CLI with the new ees built based builder,
the application builder, and we can stay closed to what
the Angler community is doing and add this federation idea
on the top. Because it's just a thin wrapper nice.

Speaker 2 (08:43):
Okay, so I I guess I thought Native Federation was
meant to specifically work with es bill, but you're saying
it's specifically meant with to work with whatever.

Speaker 6 (08:55):
Yeah, yeah, totally, But you have a good point. Our
reference implementation and the implementation that comes out of the
box is indeed yes, build based or application builder based,
because this is what we need now in the angular space.
But bodding it over to another bundler would be really straightforward.

(09:18):
I think we need less than a week, perhaps one day,
two days to board it do a different bundler.

Speaker 5 (09:25):
Nice. Nice.

Speaker 2 (09:26):
That actually makes me feel a little more relaxed. We
use native federation when you have a question.

Speaker 3 (09:33):
With the bundler being agnostic or mostly agnostic, how does
it look on the application side, because, like in the
microphone and space, one common scenarios that you have, like
an Anger application next to React application, for instance, how
does that look?

Speaker 6 (09:47):
Yeah, we can do this. So if we really want
to mix and match different frameworks, there are some good
reasons and some not that good reasons we can achieve it.
Because we can also wrap native Federation around a self
written built script people might use in the rect space

(10:11):
or have a wit integration, or if you use EARS
builds directly in a build script, you can also include it.
They are just at free commands and that's it. Of course,
if you have several frameworks, then we somehow need to
abstract the framework. Some people hides the framework behind a

(10:34):
simple interface with a start and stop method. I like
to use BAB components because also they can act as
a wrapper of everything that's used technology viz underneath the covers.

Speaker 2 (10:49):
One of the questions I wanted to ask is, so
how do you deal with upgrading Angular doing either Angular
upgrades or Native Federation upgrades? Does that mean you have
to update all the apps together or can I go separately?

Speaker 6 (11:07):
Yeah? So I really like to distinguish between this single
version solution and the multi version solution. Both have different
character characteristics, different advantages and disadvantages. If you manage to
just stick with one Anglar version, then it's really straightforward.

(11:28):
Then it really looks like lazy loading. But Angler loads
something it did not know it to compile. Then, but
then you just have one router and this makes everything simple. However,
if you cannot control this, if you cannot make sure
that all your different thems upgrade at the same moment.

(11:50):
This can have several reasons, not only technically reasons but
also organisatorically reasons and reasons that die in company culture.
Then you need this multi version solution, and then you
need a wrap around your framework, some kind of abstraction.

(12:11):
Then you need to deal with different routers because different
microf round thens can bring their own route, and this
calls for some creative workarounds. It's completely doable, we have
done it several times, but the road is a bit
more rocky do What's this?

Speaker 4 (12:31):
So? With the single version solution, can you get into
a situation where one application slice I guess if that's
a good If one application slice, let's say like you
have a monitory book for example, right, and we update
the angler version to twenty point one one zero, right,
and then we deploy like the two application slices and

(12:53):
then the root application. Right, there's three. Can you end
up in a situation where like the previous version of
the root application loads a new version of one of
the slices and then the angular version is then mismatched
between the two of them. Or are there tools or
processes that there are available to as such that like

(13:14):
once we update the single version of angular across all
of our slices. We're never mad up in a weird
mismatch scenario. How does the like Because of course there's
like CD and cashing and browser casing and chunk cashing,
and like cashing is hard. So how do we prevent
version mismatches in the single version policy?

Speaker 6 (13:35):
Yeah, so you're totally right. This can happen if you
deploy different pieces of your mono repository at different times.
Even though you have a single version policy, this just
means you have a single version at one given time.
So in this case, you could end up with a mismatch.
What do we do in these cases? We like to

(13:57):
use an X and an X candella which applications have
been affected by recent changes, and then we need to
deploy all of them together, all the effect that applications together,
and usually if you update the angler version, all of
your applications have been affected by a reason change. And

(14:21):
this also shows one characteristic of this single version solution. Namely,
it does not give you the full freedom, the full
dem autonomy. It gives you some amount of team autonomy,
but on the other side, it also gives you less
things to think about. You don't need an abstraction, you

(14:43):
only have one version. But yeah, this is the consequence
that rad off here you have more freedom with multi versions,
but also more moving parts, more things to think about.

Speaker 4 (14:57):
So then if we go a step further beyond, say
like the build and deploy time, what happens in the
case of where like let's say i have root version
one loaded in my browser, right, and I'm on some
page that has you know, child version one, right, and
then Manford, you go and update Angular. Everything gets affected,
everything gets deployed, right, So now everything's on version two

(15:20):
and I navigate to another page that would load child two, right,
how does my root version one not load child version
two and then have an incompatibility mismatch? Or how do
you prevent like someone's existing application or cased application from
loading from a CDN an invalid version because of the

(15:43):
version mismatching.

Speaker 3 (15:44):
Just to a hard to refresh on every navigation?

Speaker 4 (15:46):
Oh, hard refresh on every navigation? Okay, got it right? Yeah,
I'm sure that is the answer.

Speaker 6 (15:52):
Yeah, I mean I'm in hype. But link in decoration
is indeed's the symbol solution, and we see it's in
some area, especially when we talk about product suits like
Office three sixty five or the Google suits where Google
Sheets and Google Forms is a completely different application. And

(16:14):
in my opinion, it's okay as long as you don't
need to switch around for a single desk. If you
need to switch around for a single dosk, and if
you have to go with ten page refreshers, then it's
really a mess, you know. But otherwise, if you say,
if I do an article, I'm sticking with Word for

(16:37):
the next six hours, if I do the buttshed for
the next year, I stick with Axle for the next
six months, then it might be okay. But if this
is not the case, well, if you really have several
versions side by side, then each version needs to have
some MATA data. This can be as simple as a

(17:02):
chasing file that is published with the Shell application, or
perhaps you have something like a backhand service and NBM
rechestery for a micro round THENCE that tells you, oh,
you are the Shell in version one. Here, I have
those micro round thence for you, and you are the
Shell in version two that is only rolled out to

(17:24):
friendly users so far, and here is the list of
you are microfroundans.

Speaker 4 (17:30):
Yeah, so it's not I'm going to go load child too.
It's like, what child toos do I have access to?

Speaker 8 (17:37):
Bet, I'm going to pick the child too, I have
access to which would be version one or version two
depending on what child map right importan math effectively Yeah,
yeah you.

Speaker 4 (17:48):
That shell knew about at build time kind of thing,
m or more or less. I guess, yeah, okay, that
makes sense. Yeah, someone block listing, or I guess it's
more allow listing, just saying like, hey, you only know
how to load these things, don't just take the most
recent version from the CDN that might be incapatible.

Speaker 6 (18:09):
Yeah, yeah, totally, Yeah, Yeah, we need this meta data.
And I think this also shows that we have to
implement a bit to provide a foundation for our architecture.
Sometimes the static chase and file might be good enough.
Sometimes we want to have our own registry where we

(18:31):
can do a quick roll back perhaps, or where we
can give just friendly users during ap testing access to
new vertically something like Yeah.

Speaker 2 (18:42):
I think I think it also really touches on. I
think the biggest struggle that we have had with one
of the biggest struggles we've had with microphone and architecture
is local development, because you're not just running one app.
You're running like three apps, so what are what is

(19:03):
your go to solution for local development with the microphont
and architecture.

Speaker 3 (19:08):
So really quick, I'm why are you running three apps?
Is that the whole idea that one team is working
on one that's fair?

Speaker 2 (19:17):
So for example, we have our like shell app, which
is the host, that's the one that knows, that's the
one that has the routes that lazy load the child apps.
And then so if you're working on app A and
app B or honestly even just the Shell and app A,
you have to have the shell running to be able

(19:37):
to load app A, And so you either have to
run the shell on your machine and then also run
app A on your machine so that app the shell
can load the running app A into the shell, or
you have to pull a running version from somewhere.

Speaker 3 (19:56):
But I still confused. Why don't you just work A Usually.

Speaker 5 (20:02):
Well, so you can just run app A.

Speaker 2 (20:06):
But for example, like our app, the shell has the navigation,
so if I want to test navigating into.

Speaker 3 (20:13):
Yeah like stitching things together, okay, yeah, yeah.

Speaker 5 (20:15):
Yeah, yeah, yeah.

Speaker 2 (20:16):
You can do local development to a certain degree. But
then you're also like our shell provides authentication, and like
a lot of other stuff that the the individual apps
themselves don't necessarily know about. And then if you want
to try to test integration between apps like that is
also a nightmare because then you got to run all

(20:38):
of them.

Speaker 5 (20:39):
So yeah, thank you, Yeah you're welcome.

Speaker 6 (20:43):
Yeah, you need to do this, especially when you need
to test integration or if you need something from a
different microfound and Dan yeas I would say, ideally, I
know it's not always possible, but ideally, in this beautiful
shot any world, we might imagine you have the maturity

(21:05):
of the tasks in just one application. And perhaps this
one application, when it starts in development as a standalone application,
it has already baked in dumbyshell, a dumbichell that gives
you some dummy implementations of a shell service like authentication
to fake user. You just have to make sure that

(21:27):
the dumbyshell never makes it to production, because then you
really have other issues. Give me to test the integration
or the communication. Then you need to start more than
one application. Hopefully this is not in the maturity of cases.

Speaker 5 (21:45):
Yeah, interesting, what are the okay?

Speaker 2 (21:50):
So sometimes there are services that you have to share
between microphone applications you obviously don't like. Like you said,
they're meant to be very discrete apps that don't necessarily
know much about each other.

Speaker 5 (22:05):
What have you found are the most common.

Speaker 2 (22:07):
Services that you need to share between the different apps.

Speaker 6 (22:11):
Yeah, it's often some kind of context information that is
wellid system wide. It can be a handful of primitive
dot dot diypes like who is the current user his
or her ID? Or do we talk about this standard
or a different eend? Or do we talk about this

(22:34):
physical year or their last physical year? Something like this,
some general context information you want to share for the
sake of usability. The user don't want to select the
same data diamand again you should not share stuff for
the case of caching, because this really couples your domains together,

(22:58):
and it's also a trade off. If you really go
down this road, you sometimes might load the same data
in different domains, in different microfroundands, and you don't catch
it because you don't want to bind yourself to other verticals.
On the other side, chances are that it is not

(23:19):
exactly the same data because often in different domains you
have a different perspective to the same data. A product
from your stock perspective looks different than a product from
your shop perspective or from marketing, so it might be
the same but in a different shape. Yeah. And another

(23:41):
thing we often share is a simple let's call it
shell service, a service with weel please now display this
to the user in a unified way, an a message
pop it up, or a dosed message. Perhaps we don't
even call it dosed. Perhaps we call it in neutral
way so that the shell itself can decide how it's displayed.

Speaker 5 (24:06):
Interesting.

Speaker 2 (24:07):
Yeah, one of the things we share is feature flags,
but I don't know if we're supposed to do it
that way, so.

Speaker 6 (24:12):
It's possible, or you could also define that each and
every vertically, each and every microfront and has its own
feature flags.

Speaker 3 (24:21):
Yeah.

Speaker 2 (24:21):
I think we have the base services part of the shell,
and then each service, each micro service defines its own
set of flags that it uses.

Speaker 5 (24:31):
So man, it's complicated.

Speaker 6 (24:34):
So yeah, and it's always trade off. There is no
right solution. It's always a trade off. I think if
you are aware of this tradeoff, and if it is
a deliberate decisions where you take all the bros and
cons into account, then it's fine.

Speaker 3 (24:52):
So if it just.

Speaker 6 (24:53):
Happened by incident, then perhaps you might end up in
an in an how do you call it that?

Speaker 2 (25:00):
And yeah, yeah, so if you're if you were so,
Let's say you were taking on a new client and
they were considering implementing microphone and architecture with federation in
their and their apps. What kind of questions are you
going to be asking to determine if they actually need it.

Speaker 6 (25:21):
Yeah, that's that's a good point because I really like
the idea of microfroundance and I have helped a lot
of companies with it, but I have also advised against
it quite often because it does not always fit and
if you use it without really a need, then you

(25:41):
have a lot of troubles, a lot of extra work
to do. So the first thing is I want to
find out why they need this kind of architecture, and
if it is not about steam autonomy, if they would say, well,
it's totally fine, we only have one or two teams
and they can perfectly work together in one mono repository,

(26:05):
then I would really stick with something like an AX
and or a share with because it's a default architecture.
We get everything scareful that everyone knows it and it's
heavily tested, so I would really stick with it. On
the other side, if you are a bank that says, well,

(26:25):
we have different developers around the entire clube with different
betteralist knowledge and they don't work together. They are in
different knowledge spheres and putting them in one mono repository
it does not work. Then yeah, this approach is quite tempting.
Then perhaps we need to make sure they are not

(26:46):
running into open knives, that they are doing it safely,
that they are aware of some challenges like you know,
different routers or abstracting different versions of different frameworks, stuff
like this. But this is then the roads we go down.

Speaker 3 (27:05):
Good morning, you know that moment when your coffee hasn't
kicked in yet but your slack is already blowing up
with Hey did you hear about that new framework that
just dropped?

Speaker 6 (27:14):
Yeah, me too.

Speaker 3 (27:17):
That's why I created the Weekly dev Spur, the newsletter
that catches you up on all the web deaf chaos
while you're still on your first cup. Oh look, another
anger feature was just released, and what's this typescripts doing
something again? Look also through the poor requests and change
shot gramma so you don't have to five minutes with

(27:39):
my newsletter on Wednesday morning, and you'll be the most
informed person in your standard. Ah, that's better the Weekly
desper because your brain deserves a gentle onboarding to the
week's tech madness. Sign up at Weeklybrew dot dev and
get your dose of deaf news with your morning caffee.
No hype, no clickbait, just the updates that actually matter.

(28:01):
Your Wednesday morning self will thank you. Would you generally
say that doing microfundance in a mono repository is easier
versus when they are separate or poly rapos.

Speaker 6 (28:16):
Yeah, it's a bit easier because you are forced to
just have at least one version at one time. Also,
sharing stuff is easier. Of course, in theory we should
not share a thing, but in practice sometimes we need
to share something, and if it is not use case specific,

(28:37):
it's something technically we need to share our way of
doing authentication in our big corporation, for instance, which is
quite common, or our design system, and yeah, this is
this is easier to be shared in a in a
mono repository. Saying this it does not give you the
full team autonomy. It gives you a bit of it.

(28:59):
But this it gives you also some some advantages less
pan when sharing things.

Speaker 3 (29:08):
What are some of the most common issues you see
with people adopting.

Speaker 6 (29:15):
Microphone Well, I think one difficult topic is not even
a technically topic. It's about slicing the system into parts
that don't need to know much about each other. Because
there is never a perfect way of slicing things. There
are several heuristics do main driven design has defined some

(29:39):
of them. They are in handy, but at the end
of the day, you only have possible candidates for slices,
and none of them is perfect. So this is one
of the challenges. You have to find out which of
those candidates have more advantages than disadvantages. And when you

(30:01):
start sharing libraries, sometimes if you have an exotic library,
it might cause some troubles. It's becoming better and better
because we gain more and more experience with this kind
of exotic libraries or libraries we would not have expected

(30:23):
to do this or that's that way. But yeah, sometimes
if we compile it to be shared at run time,
we have some issues, like one best that it with
this compilation mode, with this off level usage of compilation.

Speaker 3 (30:40):
Do you have an example of such an exotic library.
I'll just wrap my head around it.

Speaker 6 (30:47):
Yeah, so one example we have. Meanwhile, it's solved. But
one thing we did not think about is a component
library that has a taming system that is separate from
the component library, and if I compile both of them

(31:07):
separately so that they can be shared separately, at run time,
they don't know about each other, which might be a
good thing at first sight, but at second sight they
have been designed to know about each other because the
component library is asking the theming library about colors and shapes, and.

Speaker 3 (31:27):
So yeah, that makes sense.

Speaker 6 (31:29):
So meanwhile, we have a solution for this, but this
was one of the things we did not think about originally.

Speaker 2 (31:37):
I think it's hard to so my team, we were
working exclusively in a mono repo, and so switching the
microfront ends has been it's been a challenge just because
we're used to the mono repo, and I mean we're
still in a mono repo, which is nice because we're

(31:59):
really kind of getting away with it, but at this
point we've seen a lot of additional complexity. We use
a registry to run locally, so if I run my
app I'm working on locally, it just pulls down what's
on dev for the shell, which works fine, but it's

(32:20):
another point of failure. So if anything goes wrong with
that that registry, then there's another point of failure there.
And you know, when you're developing a new system, like
from the ground up, it can be really like not
only are we developing things, but the teams that are
supporting all the pipelines are developing things and all of that,
and so there's just we've had a lot more points

(32:42):
of failure that have been really difficult to kind of.

Speaker 5 (32:47):
They cause delays.

Speaker 6 (32:48):
I completely feel you, and this brings us to a
critically point. If you really want to succeed with this
architectural style, and I have seen this at several customers,
you need to have a blood form team that takes
care of all those issues so that the feature teams
don't need to do research, don't need to reinvent the

(33:10):
wil I have seen huge systems with eighty teams around
the globe and they had three people, three architects in
the in the blood form team that have foreseen the
possible issues, that developed solutions for them, so that the
majority of the future teams just could have done but

(33:31):
they are supposed to do namely produce business value in
their areas.

Speaker 5 (33:37):
Yeah, I could. I can back that up as well.

Speaker 2 (33:40):
One of the things that we did early on was
we wrote several generators like nex plug ins, so that
when people wanted to make a new app, they didn't
have to know how to configure it to work with
the front like with the microphone end. It just it's
born that way. Same thing with all our light like.
So we support a we the generators, which have been

(34:02):
very helpful because that was definitely as a feature doing
feature work, I don't want to have to think about
how do we configure the microphont end now because also
it changes, especially as you mature and realize okay, that
doesn't work now, we need to move on and do
it this way. So yeah, because if you look at
your example, your example looks very simple. Oh, there's a

(34:23):
host and then and then there's remotes, and I just
have to tell the host where the remotes are.

Speaker 5 (34:29):
It's easy. And then they're like, oh, except what about
Yeah there's a lot of what abouts.

Speaker 6 (34:36):
Yeah, I completely feel you, and having gender rate us
is really a great way to get those issues at
least partially solved. It's bad than such a documentation, you know,
because I don't know about you, but here in Austria,
we don't read a lot of documentation. We just work,

(34:57):
you know, and so we have to generate that you
get it generated and then you have at least your
skeleton that is not not not not fully wrong, that
already goes into their right direction.

Speaker 3 (35:13):
Yeah.

Speaker 2 (35:13):
I love putting in the generator too, like this is
how you run it, because that's usually the command people
are like, how do I run this thing?

Speaker 5 (35:20):
Again?

Speaker 2 (35:20):
Like this Like okay, you just have to so so yeah,
it's a great place to document that kind of stuff too.
And also I would say with AI, like I don't
love to write documentation. AI is good at writing documentation,
but it is soberbose that I don't want to read it.

Speaker 6 (35:35):
Oh yeah, perhaps we have to use it on both sides.
Wants to blow up some words to sentences and then
shrink it down the words again.

Speaker 5 (35:46):
Just give me the three things I need to know
how to this giant text.

Speaker 4 (35:50):
Yeah, yeah you do.

Speaker 5 (35:56):
Oh that's funny.

Speaker 2 (36:00):
So what are some of the best applications that you've
seen of the microfront and architecture, Like situations where it's
just really working for people.

Speaker 6 (36:10):
So one example is this huge car manufactorer that wanted
to streamline the communication with their traders out there. And
I did not know before, but there is a lot
of communication. They have about eighty domains, eighty verticals, with

(36:30):
all the possible things like doing a test drive, doing
an insurance, sending you some cars you can have their
perhaps they are sent back when they are not sold.
Stuff like this. So really dozens of things. And yeah,
they sit around the globe and they even use different
technologies because it was not possible to force all of

(36:55):
them into one tax stack. Some of those applications have
already been there and just needed to be integrated. So
they have a very smart shell that not only knows
how to load via Native Federation, it also knows how
to load via Marshall Federation, how to load via iframes,

(37:15):
how do loads via web components, just to bring everything
together to this one integrated trader platform.

Speaker 2 (37:24):
Interesting, Okay, so you like in theory the shell can
use more than one federation strategy or even iframes.

Speaker 6 (37:32):
Yeah yeah, yeah.

Speaker 5 (37:33):
Interesting.

Speaker 6 (37:34):
Also SAP is doing this. They have this Luici framework.
They had a similar challenge integrating existing solutions to one
big cloud based solution.

Speaker 5 (37:45):
Interesting.

Speaker 2 (37:46):
I'd like to that you point out the different teams
because I know, so we're an Angular team at Cisco.

Speaker 5 (37:51):
There's a lot of React teams at Cisco's.

Speaker 2 (37:53):
There's also some View teams at Cisco, and it is,
you know, I think as Angular devs, I know a
lot of us always get the conversation of well, why
don't we just use React? It comes up a lot.
You know, it's like, well, because I want to. I mean,
actually I have a whole list of reasons why why
I prefer to use Angular, And especially like on our teams.

(38:16):
You know, we work across the globe, we work with
hundreds of other developers. I like the guardrails I can
put into Angular. I've had issues working with React. I
know that some teams are very successful working with React,
but I know no team that likes to be told
I know you're a React team and now you're working

(38:38):
in Angular, or I know you're an Angular team and
now you're working in React. And so it's that is
one benefit of it. But again, like you said, it
requires a sophisticated platform shell to be able to pull
that off.

Speaker 6 (38:55):
So yeah, it's really broad checked within the broadchat to
make a sound platform.

Speaker 5 (39:02):
Yeah.

Speaker 2 (39:03):
Yeah, So if you're gonna if you're to the listeners
that are out there thinking should I use a microphone
and architecture? First of all, A do you need it?
What are your reasons for needing it? And B just
know you're going to spend some time on that shell
app to make it work right for everybody. Also, don't
forget local development.

Speaker 6 (39:23):
Yeah, and if you just have one deem, then chances
are you don't need it. It's an overkill. Perhaps there
is one exception to this, which is somewhere in between
microft round dance and the black in system technology bias.
It's about the same on a logic level, it's something different.

(39:45):
But let's say you have a software as a service
platform for severaldenance, then you might need to load some
blug ins for some of your tenants and different plugins
for different dance. Then it also might makes sense if
you just have one team, But then it's more like
blacking scent less like real microfrontance.

Speaker 4 (40:08):
Is there I'm sure the answer is it depends.

Speaker 6 (40:11):
But is there kind of like always depends?

Speaker 4 (40:13):
That's always the answer, right?

Speaker 5 (40:14):
Is it depends?

Speaker 4 (40:16):
Is there like a point that you would suggest for
someone like someone is in a company would go to
the go to the microphone and native federation type system
versus just like a single hap like is it probably
four teams with each of their own Like I'm sure
that there isn't actually an answer, but maybe some of

(40:38):
our illsteners are thinking like am I on the line,
like should I be using this? Or should I not?
Or am I not big enough? Or my too small?
Like I'm sure there's no answer, So can you verify
that there's no like actual like hardline where you where
you decide to.

Speaker 6 (40:52):
Yeah, so it's it's indeed, it's hard to tell a
number because one of the things I had to learn
when it was all they are consulting companies. It really
also depends on the company culture. For some companies, it's
a nightmare. Then four teams need to work together in
one rabusitory, especially when they have different knowledge areas or

(41:17):
a different background. And then I have seen companies where
it is totally fine to have eight or ten or
even more teams working together in one mono repository. Culture
is for sure one thing that influences this. The question
is also which pain are you are you up to

(41:39):
take on? You is it a pane of micro front
and integration or is it some other kind of pain
you have in a big mono repository. Also there you
have some challenges and which Paine is, but you can
take better.

Speaker 2 (41:55):
Yeah, I wonder if it's easier to write a platform
shell that can handle the difference and how like how
like can a platform shall actually solve the problem of
team like lack of communication between teams or does it
exacerbate it, like does it make it worse because like
there aren't following rules or something.

Speaker 6 (42:18):
That's that's the big question. So yeah, perhaps if we
have different domains that really don't need to know much
about each other, just is container with data that is
sometimes coming from left to right. Like let's say I
I purchase a product here and then I just sent

(42:42):
Oba the least with the items that have been purchased,
and then you are responsible for shipping them. Then it
might work quite nicely. If I need to jump around,
for one desk between a lot of different microfround thens,
different teams built, then this might not be the best
user experience.

Speaker 2 (43:05):
What problems do you see people trying to solve with
microphone ends?

Speaker 5 (43:08):
That microphone ends just can't solve m.

Speaker 6 (43:13):
So what can microfront and is not solve Well, you
still need some amount of communication between the teams because
there's always an interface between those teams and the barts
the teams are implementing, because there is a reason why

(43:34):
it's one system and not two systems. So some amount
of communication you will always have, and you also need
some kind of of governance. In theory, you have all
the freedom with microfround thence, but in practice you should

(43:54):
limit yourself a bit. We don't want to have a
framework zoo. We don't want to use all the possible
frameworks just for fun. Perhaps there's a good reason, as
you say, you have talent for a react, you have
talent for Angola, and you'll have to utilize this talent
and forcing people into using a completely different framework is

(44:17):
not especially motivating. So yeah, this is a good reason,
but just for fun introducing further frameworks just for fund
saying oh, swelled is nice and solid chess is nice.
Let's added to the game, because why not. It's possible
this would be the wrong base, so you need some governance.

Speaker 2 (44:36):
Yeah, I could see that well, and you know too,
like the more different versions, everything is on it's just
more code that's getting pulled down into the browser.

Speaker 5 (44:47):
And so yeah.

Speaker 6 (44:51):
The hopefully lazily, but yeah, it's still pulled down at
some point in time.

Speaker 2 (44:56):
And yeah, interesting, Okay, so what does the what does
the integration testing story look like with microphone ends? Why
did you sort of go to with that?

Speaker 6 (45:09):
So ideally the maturity of tests are isolated to one
microft roundant, but we also need integration tests. I would
say we need them anyway, but they are more important,
even more important when we have micro round ins, because
you have to make sure that those moving parts play

(45:30):
well the data. Then they meet for the first time
at runtime. So usually you have some kind of staging
environment where you but relish everything, where you test everything
and only if it works there you move it further
into production.

Speaker 2 (45:46):
Do you do like when you do tests like that?
Do you do like a full stack integration where you're
just literally just running the app and say writing like
a playwright test to just make sure that you can access.

Speaker 5 (45:57):
Each of the apps?

Speaker 2 (45:58):
Like what level of testing are you doing at that point?

Speaker 6 (46:02):
Yeah, so it's this kind of testing where we know,
at this point in the application we need to phone
over to another vertically to another microfroundance or if you say, well, here,
we have the hyperlink going over there, and we need
to send over the sporameter so that we can go
on with the with the task over there. So this

(46:26):
is something I would focus on.

Speaker 2 (46:28):
But mostly just the like the connecting points, not so
much the if I go over there, and then I
can go ahead and do this task, like the task
should be tested within the app itself, and then you're
just connecting.

Speaker 5 (46:40):
You're testing the connection points. Mostly yeah, yeah, okay, that
makes a good Yeah, that makes sense. What other like,
what are some of the biggest gatcha's you've seen with people.

Speaker 2 (46:54):
Using microphone architecture, Like mistake common mistakes that people make
that that you want people to avoid.

Speaker 6 (47:03):
We have one for shures using it when you don't
need it, and I would say the maturity of projects
out there don't need it. We also see this in our.

Speaker 9 (47:14):
Workshops where we discuss several architectural styles and the majority,
let's say two thirds, always say, well, we are good
with a monolith, a monolith that is nicely structured internally
in terms of.

Speaker 6 (47:28):
All dos or libraries we share with and or an X.
But as soon as you have several tams. People say,
and often this is one third of our audience in
public workshops. Then of course they say, yeah, we have
to go the difficult way and we have to apply

(47:49):
some kind of microfround and strategy. So this is one mistake.
Using it when you don't need it. Then of course
you need to have a platform. If you don't have it,
you will fail. I'm quite sure you will fail. I've
seen this several times when people did it just for
fun without a joint foundation. It's really a nightmare. You

(48:14):
have to think about sharing, but not over sharing stuff,
and somehow you need some kind of design system. Most
people share it via libraries or MBM packages.

Speaker 2 (48:29):
Makes it because you don't want your app to look
like it's five different apps patchwork together.

Speaker 6 (48:36):
Should not look like a Franckenstein creature.

Speaker 2 (48:39):
Right unless you're just like, that's who you are, that's
your company incorporated exactly, doesn't matter what it looks like.

Speaker 4 (48:50):
I feel like the well structured monolith solution can get
you pretty far. That's what That's how Trials operates like.
We have multiple apps, but not in the micro front
end type situation. They're literally just like very different business cases.
But there's like there's two or three, like two that
are pretty big and then a couple like smaller ones.

(49:12):
And I think that like for us at least, we're
all small team though, right it's me and then three
others and are developing, right, so and we all work
on everything. But the model iss have gotten us pretty
far in terms of we have yet to come across
the situation where we feel like micro front ends are
even remotely in the conversation for solving any of our problems.

Speaker 3 (49:33):
It just needs to way to like the see money
is involved. You scale up like twenty teams in two weeks,
and there you go, and we're.

Speaker 4 (49:40):
Way past seed stage. Man, we're way paste stage at
this point, and we're not raising seed rounds like these.

Speaker 3 (49:46):
AIBC said, Okay, yeah, I know you're around for a
little bit.

Speaker 6 (49:55):
But yeah, that's a really good situation. I always say,
and I have really done both and was a young engineer.
Under engineering is as bad as oboengineering. In both situations,
you end up with a solution that is more difficult
to be maintained than necessary.

Speaker 5 (50:14):
Is it difficult?

Speaker 2 (50:15):
Like say, let's say Jay, they do get twenty more
teams and they think, ah, now, is the point where
I think we do want microphone and architecture. How difficult
is it to apply to an existing application.

Speaker 4 (50:31):
That's a question for you, because I have no idea.

Speaker 6 (50:34):
You could use an ex module boundaries or share if
and if you do it, you nowadays already have the
benefits that not everything is in doming it. But if
there are some boundaries, it's easier to migrate to a
later point in time, at a later point in time
to microfroundance. And if we don't need it, even better,

(50:58):
then we stick with a simple solution. So this is
an approach I really like to go with.

Speaker 2 (51:04):
Yeah, just if you're not sure if you need it,
start with the monolith or mono like a mono repo,
make sure and define your clear boundaries between your applications,
and then if you do mature to the point that
you do need to tackle it at that point, I
like that plan.

Speaker 4 (51:19):
I think that's going to start you well, regardless of
if you go to micro friends in the future anyway,
like yeah, should they need stuff correctly from the get go,
regardless of if you even remotely figure Yeah, so our
listeners know like structure correctly, even even in a.

Speaker 7 (51:34):
Monolith yeah, yeah, yeah, yeah, Well I feel like too,
like as as I've matured as an engineer, as i've
you know, like you know, there's when you start your
career you're kind of like, oh, I'm not sure what
I'm doing.

Speaker 2 (51:47):
And then you're like, let's do all the things. I
want to try, all the patterns and all the things.
And then you get to the point where you're like,
do we wait, do we actually need this? Like this
sounds like a pain, Like mostly in my brain, what
I'm saying is that sounds like a pain. Do we
really want to maintain that? So you know, it's like
the fewer moving parts you have, the better, Like yeah,

(52:10):
like the fewer points of failure, you know, Like we've
had solutions where we're like, well, I guess we could
spin up a server that sits between here and here,
but then you got to maintain that server and what
happens when that goes down? And so there's all these
anytime you add complexity, you add more points of failure,
more complication, and yeah, you just make your lives harder.

Speaker 3 (52:28):
So jop security though, job.

Speaker 2 (52:32):
Security, I'm literally the only one that knows how this
thing works.

Speaker 5 (52:39):
I can't save you from what I did here, what
do you see for the future of module or Native Federation?

Speaker 6 (52:52):
Mm hmm, well you see currently quite a huge adoption.
So then the look into Module Federation, which has meanwhile
be bored to our as back, not to is built
unfortunately because it's too different from that back, but it
has been boarded to our ASPEC. Then we see that

(53:15):
a lot of companies are using it, a lot of
well known companies, and also Native Federation, which is nice
because it allows us to stay close to the angle
of CLI is meanwhile in cooperated by some pretty big names.
Some of them are companies we help, some of them

(53:36):
are companies we just heard about that they are using it.
And this is really awesome when you see, well, such
a big name is using this concept we have worked
with or helped to bring alive. So I think this
is one of the big things there. Another thing that

(53:57):
might help is now we are moving a bit more
back to the backhands don't be with hydration and server
side rendering. So that means that hyperlink integration is not
that painful anymore, because loading a completely new single bitch
application is pretty fast because of re rendering and so

(54:19):
so also this might might help in this space.

Speaker 4 (54:23):
Interesting, I guess we did never even we have time now,
but we didn't actually talk about how SSR factors into
this whole life.

Speaker 6 (54:29):
Oh yeah, conversation, M.

Speaker 3 (54:33):
Yeah.

Speaker 6 (54:36):
Short answer is it takes some pine away from hyperlink
integration because it's easier to jump over to a completely
different application.

Speaker 4 (54:45):
Makes sense.

Speaker 5 (54:47):
So for somebody who wants to let's say you are on.

Speaker 2 (54:49):
A team and you've decided microphone and architecture is the
thing I need. Where do you recommend people get started?

Speaker 6 (54:56):
Well, there are some good For instance, o'relli has a
good general book on microfroundance. It's written in a way
and I really like this in a way that will
even be relevant in ten or twenty years because it's
about the concepts you know, and concepts stick everything else.

(55:18):
Technology is changing, but concepts will be there in twenty years.
So this is a good starting point when it comes
to the you know, to the Mantel model. We also
have a free book, perhaps we can link hit somewhere
here that looks at the same topic from the perspective

(55:38):
of an Angler developer. It explains how to add federation,
how to share libraries, how to implement dynamic routing, dynamic
black ins and stuff like this helps those Those sources
are not bad, especially when you are in the Anglo space.

Speaker 2 (55:58):
I know, like we really in very heavily on the
documentation that you provide with your Native Federation package pretty much.
That's mostly how we got started when we set up
at Cisco.

Speaker 5 (56:14):
So that's a great place to So.

Speaker 2 (56:16):
We're getting up to the top of the hour here, Manfred.
How should people reach out to you if they have
questions or if they want to chat.

Speaker 6 (56:27):
Yeah, you can with pleasure reach out on social media.
I'm on most platforms like you know, x, Twitter, Facebook,
Blue Sky. Meanwhile, LinkedIn is currently a very friendly space.
I think it helps when everything is in there with
their CV, it helps that people stay friendly.

Speaker 3 (56:49):
Yeah.

Speaker 6 (56:49):
But also we have a contact for on our website,
so as it pleases you.

Speaker 3 (56:54):
We can put your personal phone number in the show notes.

Speaker 6 (56:58):
Yeah, yeah, please please note phone numbers. I'm really I'm
really bad at using the phone the time in silent mode.

Speaker 2 (57:06):
I don't like I know, I like mine is always
on silent. Nothing is allowed to send me notifications. If
I answer you, it's because I went looking to see
so well, thank you so much for your time today
for joining us.

Speaker 5 (57:21):
It's always a pleasure to have you on.

Speaker 2 (57:24):
I know this episode will air after ERGI Comp, but
I'm really excited to see you again at ERGIE Comp.
Will you be at any of the conferences in Europe
later this year?

Speaker 6 (57:36):
Yeah, will be at some of them, at ANCHI Poland
for instance. Nice also an shet in Berlin, so perhaps
we can also catch up somewhere at those conferences.

Speaker 2 (57:48):
Nice, Yeah, pretty much. I feel like you're at You're
at most of them. So it's always if you see
don for it.

Speaker 5 (57:53):
To say hi.

Speaker 2 (57:55):
You're always gracious happy to tell you. So Yeah, thank
you for your time today. Thank you for all that
you contribute to the community. You make our jobs easier.
We very much appreciate that, you know, and I love
what your team has been doing. I know not just
you are contributing, but a lot of the people that

(58:17):
you work with every day are also heavy contributors to
the community, and we appreciate all of the effort that y'all.

Speaker 5 (58:23):
Put into that.

Speaker 2 (58:24):
So to the listener, thank you for joining us today.

Speaker 5 (58:28):
If you would like more content like this, please subscribe
to the podcast. That's how we get the big bucks.

Speaker 2 (58:34):
To pay for editing, so thank you for joining us
today and have a great day.

Speaker 10 (58:45):
Hey, this is pressed on mine. I'm one of the
NNGI Champions writers. In our daily battle to crush out code,
we run into problems and sometimes those problems aren't easily solved.
Njikompf broadcasts articles and tutorials from NDIE champions like myself
that help make other developers' lives just a little bit easier.
To access these articles, visit medium dot com, forward Slash,
n gcomm.

Speaker 1 (59:06):
Thank you for listening to the Angular Plus Show, a
NGCOFF podcast. We'd like to thank our sponsors, the ngcoff
organizers Joe Eames and Aaron Frost, our producer Genebourne, and
our podcast editor and engineer Patrick Kays. You can find
him at spoonful ofmedia dot com.

All Episodes

S10 E8 | Architecting for Autonomy: Micro Frontends & Native Federation with Manfred Steyer

Episode Transcript

Popular Podcasts

Stuff You Should Know

Dateline NBC

Betrayal: Weekly

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}S10 E8 | Architecting for Autonomy: Micro Frontends & Native Federation with Manfred Steyer