Exploring Micro Frontend Architecture with Florian Rappel - RRU 283

Welcome to React Roundup, the podcast where we keep you updated on all things React related! In today's episode, we have an enlightening discussion featuring Paige Nedringhaus as host, our panelist TJ Van Toll, and our special guest, Florian Rappel, a solution architect from Munich, Germany. Florian, a noted figure in the web community, especially in TypeScript, React, and Microfrontends, dives deep into a variety of engaging topics.

Throughout the episode, we explore the complexities and benefits of using React, often described as a "black box" for the way it abstracts away many details from developers. We also delve into the intriguing world of Microfrontends, where Florian provides a comprehensive overview of this approach, discussing its practical implementation and the organizational shifts it can entail.

Additionally, Florian introduces his new book, "The Art of Microfrontends," and shares insights on how to manage complex front-end projects more efficiently. Whether you're a seasoned developer or new to the ecosystem, this episode offers a wealth of knowledge and practical advice to enhance your development practices.

So, tune in for an insightful journey through the realms of React and Microfrontends, and get ready to elevate your coding game!


Become a supporter of this podcast: https://www.spreaker.com/podcast/react-round-up--6102072/support.

Episode Transcript

Speaker 1 (00:00):
Welcome to React Roundup, the podcast where we keep you
updated on all things React related. This show is brought
to you by Void and top End Devs. Unvoid provides
high quality design and software development services on a client
friendly business model. Unlike all other software agencies, Unvoid allows

(00:20):
clients to only pay after the work is delivered and approved.
Visit unvoid dot com to learn more and reach out.
If you know a company that needs more professionals to
help with design and software development, that's u n void
dot com and top end Davs helps you stay up
to date with cutting edge technologies like JavaScript, Ruby, Elixir,

(00:44):
and AI. Visit topandevs dot com to join their AIDV
boot camp, weekly community meetups and access expert tutorials. I'm
Lucas Paganini, founder of Onvoid and host of this podcast.
Thank you for tuning in. Let's jump into the episode.

Speaker 2 (01:07):
Hey everyone, welcome to another episode of React Round Up.
I am your host to Dave Paige nee Gringhouse, and
I am joined by our panel as TJ Vantol everybody,
and our special guest today is Florian Raffle.

Speaker 3 (01:19):
Welcome.

Speaker 2 (01:20):
Hi, So Florian, tell our audience a little bit about yourself.

Speaker 3 (01:24):
And why you're famous.

Speaker 4 (01:26):
Oh, I would say I'm famous, but yeah, thanks for
fine words. Yeah, my name is John. I'm a solution
architect from Unique, Germany. If you know me, you may
know me from my work in the web community, specially typescript, React,
microphone and these days especially you may also maybe know

(01:46):
me because of my work in the dotnet t shop community.
I am a Microsoft MVP since and more than ten
years now now dependsen say what they do with accounting.
Then let's say of ceremony there it was always a
full year and it's now i'd say in the mid
of the years, so they always make it let's say

(02:06):
four years. I don't know, but anyway, it should be
ten years now either way. So this is also where
I spend, of course, most of my time. I write articles,
I write blog posts. I wrote a book recently, so
it was a big achievement for me. So a lot
of work shouldn't be underestimated. And I'm very happy that
finally got released. I guess the 'll talk a little

(02:28):
bit about that too, And yeah, decides that I'm contributing
to open source and on my professional work, I always
do well architecture review a lot of implementation work and
working together which is a lot of different themes and
a lot of different clients, and always having fun, just
staying on top of the say, technology advancements. And it's

(02:51):
quite some interesting time that you're living in. So let's
me in a natcha so to speak.

Speaker 2 (02:58):
Wow, that's quite a list of items. I'm not sure
when you find the time to sleep with everything that
sounds like you've got going on.

Speaker 4 (03:05):
Yeah, my rings are Yeah. The good thing is, I
mean I have two little daughters, so sleep is pretty
much off the table anyway. So and then yeah, I
mean it just always goes yeah, one step further, one
step further. And since it's all so much fun, let's say,
writing all these these great react projects, working with microphone

(03:28):
and always of course being interested and everything that's happening
out there, it's just well all too exciting to sleep,
I would say. Yeah. Sometimes. The rest, of course, let's
called vacation is the vacation with kids' date, I guess,
but at least so they're growing older. The vacation days

(03:49):
are also, my experience, a little bit expanding, right, So
starting with zero, now we are maybe a week of
vacation per year, accumulated.

Speaker 3 (04:00):
I love the enthusiasm.

Speaker 2 (04:02):
So one article that really caught our eye was one
that you wrote for log Rocket, which we will link
to in the show notes, and it's called react as
a black box. And why does this matter? Do you
think that you could give our audience, if they haven't
read it, a little bit of insight into it and
your opinion on that.

Speaker 4 (04:18):
Sure? Yeah, I mean, please read the article everyone, but
let's say summarize it in two or three sentences. If
you're using reacts, you're mostly well not using it very
much directly. Of course, you're writing let's say react components
and all that, which are pretty much only functions these days.
Most of the things that does for you, it does

(04:40):
under the hooks, which means you don't explicitly interact with
its API. And it's really just a black box. So
you just throw something in and you expect it to work.
Your components being efficient, re rendering just happening very fast.
We have a lot of stuff going on, but you
just expected to work, right, and there, of course pros
and constant is approach there. I mean, there's a reason

(05:01):
why react is successful, and one of that reasons is
certainly that the black box. You don't need to care
about what makes the decisions or what really goes on
behind the curtain. But on the other hand, of course,
sometimes you're wondering, why is my component slow? Why is
it not really behaving the way I think it is?
And this is where the black box really comes from
the other side, right in terts you because you can't

(05:22):
really see what's going on and debugging this can be
I mean, I don't know how much time I spent
debugging real components that don't behave the way I imagine
they should behave. And personally, of course, I mean you
can already see that I have both sides. In the years,
I'm a little bit torn apart. I think, I mean,
the really great achievement and what makes functional programming also

(05:46):
created that the run time is doing a lot of
stuff for you, and you get a lot of guarantees
and on your let's say programer side that you don't
need to take care of, right, you just say, okay,
I always have my state here. I can be that
no one else is filing the step because it's immutable
for instance, and all that, and you just work with
it and you say, well, all these that say what

(06:07):
makes the decisions is under the hood and it just works.
And I think there will always be this straight off
so it shouldn't be too problematic in react case. And
my personal point of view is, well, you can't have
the let's say perfect thing here that just does everything
for you and you will never complain about it. There
will always be these educses and you will then of

(06:30):
course pay the price in some debugging let's say, sessions
that you would have wanted to avoid. But yeah, that's
a surprice we pay. Doesn't mean it's perfect, doesn't mean
we shouldn't try to improve it, and doesn't mean we
can't criticize it. It just means that I think it's
a good model after all, but we should be aware
of it. And that's that's my personal point of view.

Speaker 5 (06:51):
Yeah, it's it's interesting in a way.

Speaker 6 (06:53):
This is like the classical software paradigm, like how much
you trust a black box versus how much you control
on your own. I feel like it's somewhat at least
somewhat new to the front end world, at least because
back in the day, I feel like the jQuery days
like Jquerry. I mean, obviously it's a bit of a
black box, it's got APIs that abstract things for you,

(07:14):
but you could sort of fundamentally know what JQuery's doing
under the hood, Like the code get a little bit gnarly,
but you know they're like abstracting browser APIs for you.
They're doing some basic things. And if jQuery didn't do
exactly what you wanted, it's like, okay, you at least
had a rough idea of what was wrong or how
to work around it. Whereas I feel like nowadays with
stuff like React, and this isn't really specific to React,

(07:37):
because you could make the same argument for other frameworks
as well, but there really is a lot more magic
going on than there used to be. So if something
went wrong in Jquerry, like I could probably go into
the domin at least get a high level over you
of what's going wrong. But if like reacts doesn't reconcile
my JSX like correctly in some situations, I mean, I

(08:00):
certainly ran into and this is rare, but sometimes I've
run into React situations where it's like, oh man, like
unless I unless I google it and find somebody that
ran into the same problem that has like some ideas
of what I can do, Like it can be I
can be at a loss because it's just there's a
lot more complexity in the front end world than there
used to be.

Speaker 2 (08:18):
And there's just some use cases that React doesn't have
a solve for. And this I think this came about
earlier and reacts life cycles, like when it was still
using a lot of class based components. But there were
some situations where if you, like you wanted a model,
for instance, to just pop out and sit on top
of everything else that you could then either interact with

(08:40):
or just close and go back, it was really really
hard or darn near impossible to make that happen in
a way that made sense or was as easy as
some of the other JavaScript frameworks like Angular made it.
So there was a lot of at least for me
when I was getting familiar with React and starting to learn,
but there were a lot of really frustrating moments where

(09:02):
I couldn't do things that I would have been able
to do pretty easily in other JavaScript frameworks. But at
the same time, it's funny that you make that comparison
of it being a black box, because that's almost something
that I haven't heard React described as in a very
long time. It seems like Angular really took that and

(09:23):
got hammered a lot with it because of all their
specific syntax and components and the way that they wanted
everything built and styled. But everybody's like, oh, react, you
can do anything with it. But you're very right in
that if it's something under the hood that we don't
have either access to or any understanding of that's in

(09:44):
their source code, yeah, we're limited in that regard.

Speaker 4 (09:49):
I mean the Angle that example is a good one,
because that is I mean, if you look at angle
and that's right, it a couple of times saying I mean.
There may be some folks in the audience who completely
disagree with me, but for me though, it felt wrong
because they pretty much reinvented everything and you couldn't even
use other stuff from you, I mean the plane JavaScript ecosystem,

(10:10):
because I mean you first had to wrap it in
some angle, a specific notion of a service or you know,
following all their terminology and what they I mean that
they made a great thing, but it was in my
opinion always why do you need to re engineer that
that's already there? Browdlary ships? Is that why? But you
need to wrap it just to bring it to your framework,

(10:31):
and so I mean Angler maybe on the run time,
people may disagree with me, less complex, and then what reacted.
Certainly there are other areas like injection for instance of
what it does with me that day, the reflection and
song where it is certainly more complex. But if you
look at the chorretit right, the reconciliation algorithm. Here what
really makes reacts special. So this is a lot of

(10:53):
complexity that's completely hidden from you doing let's say your work.
Usually whereas Reacted, Angler was always on this change detection
algorithm and so in this case a little bit more
lads weight. But then it brought all these complexity also
in form of all what you could call a black box,
because it was also just throwing terminology at you and
use everything from our framework and we then do something

(11:13):
under the hood which goes back to basic browser APIs right,
So you could look at it from two angles, and
certainly in some perspective Reacted was very open and Angler
was a black box. But from other perspective and this
is really where we look at the core run time,
it's the other way around. And then of course you
can ask, well, what is the better way personally, I mean, hey, already,

(11:35):
I guess we gave enough things. I think the React
way is quite good, even though, and this is great
that you mentioned the model. React always tried to then,
let's say find solutions. So they introduced from the portal API,
which is a great API in my opinion. But in
the last two three four years we got a lot
of new APIs. I mean, starting with hooks. You've got

(11:57):
all these things that you certainly now use from Reactor.
Previously we're only using i mean create elements unknowingly, but
the class component knowingly. And now it's it's really a
lot of things like lazy you should use I guess
all the hooks of course, because they're awesome, even though
highly debated. And so now you have this whole zoo
and I'm not even starting the strict mode and all

(12:19):
that stuff, so that they also should know. So also here,
I mean suddenly complexity goes into the API comes that
the user and you now need to make decisions. So
it's it's not as severe as the Angular but it
starts also to shift. Here are the worst cases. Of course,
if you have the API complexity like angular class, you
have the internal complexity because suddenly you need to know

(12:42):
a lot of things to use it, and then you
need to look to know to know a lot of
things to debug it. And it's just like, oh, I
don't know. I mean, let's hope it doesn't go in
that way. If it goes X will not be as
successful anymore. I suppose, I don't know.

Speaker 6 (12:57):
I'm serious, Like, based off this, like what advice you
have for like the just the average React developer, like
building their their apps. Is this something you think people
should just be aware of? Is this a reason to
like avoid React or use it only when you need it?
And I'm curious what advice you to have people?

Speaker 3 (13:17):
Do you still reach for it?

Speaker 4 (13:20):
I mean I always reach for it even though I'm
very let's say open for alternatives. There are these days,
I mean a lot of what I would call lightweight
alternatives to React, things like solid chats, for instance, which say, okay,
what React brought to the table, how you write components?
This is really great, but maybe what other frameworks bring
to the table. Let's pick for instance, swells Swelter in

(13:41):
my opinion, also an awesome framework, is also good. So
how can we combine these to make for instance, the
amount of JavaScript that we ship to the user. Yeah,
less heavy, and I mean this was always one concern
with these let's say more bloaded frameworks, I mean React.
It is certainly not in that when when Angler started,

(14:01):
I don't really want to that they bash Angler, and
please forgive me for always mentioning it. I'm just an Angler,
and you always think of theven I thought so anyway,
I was always shipping. I saw at least the guy
shipping for Hello worlds six hundred and seven and eight
hundred kilobytes of JavaScript Mini Fight. Of course, jesuits a
little bit less, but nevertheless, it's nearly a megabyte. And

(14:23):
all you did was I don't know, using HTP service
in there, and it really some elementary stuff but not
really a lot of pages, just you know, one one
simple page. It was just fetching something. And of course
in reactually could have that a lot more lightweight, but
you still would ship I don't know, one hundred fifty
one hundred and twenty something. That's that still three digits
amount of javascripts for all you do is catch maybe

(14:46):
one resource and display a little string on the on
the screen. Now, of course, one could argue, I mean
this is not what REEC was built for. You should
then build a real single page application, and suddenly if
you have I don't know, one of the half megabytes
of javascripts, hopefully lazy loaded in chunks and so on,
then it suddenly makes sense you can afford bringing React

(15:07):
and React on, especially react on. I mean, React is
still white weights to the end user. But then we
have now these other frameworks like solid and they're really
aim for let's pick this small use case apart. We
can still help you make you productive, and then we
just shift the minimal amount. So what is my recommendation?
If all you want to do is write with something

(15:28):
really simple, one screen, just look around. You will find
something that will suit you from how you approach the
thing as a developer, with a community, also enough documentation,
and maybe also being efficient and white weight. If you
say you're building a full single page application, a tool
like experience I always call it, we'll say you're building

(15:49):
the next Photoshop in the browser something I mean, React
is certainly a good choice. You can certainly afford shifting
this one hundred one hundred twenty kilobytes. Additionally, which Jesus, Jesus,
maybe I don't know fifty forty KO pipes. I don't
know something in that range, so that certainly doesn't make
a great difference, but that would be my recommendation. There
are a lot of great frameworks, and I mean the

(16:10):
principles and the parading that reacts to the table you
can find now in a multitude of frameworks, and there
are really some great ones. Just because they don't have
so many stars or not take by by Facebook doesn't
mean they're worse. Just look around, make sure that they
are properly maintained, and not just stop tomorrow.

Speaker 2 (16:29):
Yeah.

Speaker 6 (16:30):
Well, and I think it's just decent software development advice
in general. Right, Like, abstractions in themselves are not bad.
Black boxes are not bad, but you have to accept
a certain amount of trade offs. You have to make
sure if you need the abstraction, if you need that complexity,
if you're dealing with that level of problem, then great,
Like that's a trade off, it's probably good for you.

(16:50):
But if you're solving a much simpler problem, you could
probably reach for a much simpler tool at least to
start with.

Speaker 4 (16:59):
Right, right, And I mean, discussion with obstruction is also
not newer, but I'm surprised that these days, it seems
like obstructions, well, at least there is a little bit
of let's say, a trend in articles to say obstructions
are bad becauseous here, and I mean, of course they're right.
There's no simple solution to say, oh, I mean always

(17:21):
obstruct a way we've seen any angular example story. Again,
it will be a theme that I guess that too
much obstruction will just hurt you because you need to
learn all these things too, right. So it firstly starts simple, oh, well,
just one obstruction, I can save these three linns. But suddenly, oh, oh,
which obstruction did I use to abstract these three lines?

(17:42):
I need to find it? And suddenly you're more concerned
about finding the right function that you extracted formally than
just to do the coding right. And so there's always
this straight off and there's certainly no one site fits
some all solutions here, like with everything right. So this
is one of the things that are always criticize many
art because only say oh this is good or everything

(18:02):
else is bad. Yeah, I mean there's always a reason why.
For instance, why exists, even though why is now bad
and excess the new thing to do, right, there was
a reason for that and we shouldn't forget that reason. Maybe,
of course technology advanced and maybe why is really not
the thing to do anymore, but maybe there was a reason,
and that reason just well, in this context is not

(18:25):
valid anymore, or something else should be, let's say, considered too.
And it's always good to know the tradeoffs and what
other things exist and in what context that makes sense,
because yeah, I mean there is in my opinion, there
is no real black and white always it's just great
and you need to find which shade of prey you
fits to your particular problem. And I guess, yeah, we

(18:48):
can discuss it in the REACT context, but I just
said it's all in soft I mean, I guess also
generations of what we knew that and we also learn
it again, at least I do. And it's always a
little bit of this cycle that that goes around, and
we just need to see right where we end up,
is where we are currently, and what we can do
to just yeah, not make the same mistakes again. I mean,

(19:11):
I think this is the only thing to really go forward,
to reflect a bit and to find let's say, a
better way forward, and to not forget why we picked
that one. The why is quite often really crucial.

Speaker 6 (19:24):
Yeah, I feel like that the EBB and flow is
an interesting way of putting it, because I feel like
that's we've had cycles like that before, even in the
front end world, Like I remember there was a time
where pretty large JavaScript frameworks were quite popular. There are
things like Dojo and Sencha, things that were fairly fairly
heavy that got popular for a while, and then there

(19:45):
was the push towards jQuery and like smaller things, and
then now we started to creep back up again with
some of these JavaScript frameworks. And I almost feel like
this is true in the bill tools world as well,
Like there's I mean, there was a while where Webpack
had like a monopoly and everybody was totally cool with it,
and now it's like cool to be like counter webpack

(20:07):
and to be using all these hip, new, strangely named
tools that are like different and smaller and faster, and
it's like we can just as an industry, we can't
make up our mind, Like as soon as we go
too far in one direction, we come.

Speaker 5 (20:21):
Back in the other.

Speaker 2 (20:22):
Yeah, it's very much a pendulum of popular opinion. But
one thing that I remember from a senior developer telling
me once, which I liked a lot was that if
I could explain to him why I had chosen a
particular way to solve a problem or style or whatever,
he was fine with it. He just wanted a reason

(20:43):
for why I was choosing to solve a problem other
than well it was like this and the rest of
the code, or I saw somebody online do it, or
somebody told me if I had a valid viewpoint. He
was totally good with it. It was just have a
reason for why do you think to do it this way?

Speaker 4 (21:02):
I think there's a good attitude. But I mean cod
re views or let's say, yeah, just knowing why things
went in a certain directions are always good to let's say,
be based on well, this kind of knowledge because at
the end of the day, I mean, there will be
always also new people joining team class of course, people
that are not as on your level or as senior

(21:24):
as you, and so for them knowing the reason is
also really good at a learning experience, either to the company,
to the project, or to software development in general. Right,
And so I always think that quite often we are
not asking the why or answering the why good enough,
at least I know that for myself. So I think
this is always something where we can be also, yeah,

(21:47):
full of critics of ourselves and always try to improve.
And yeah, I think the why question is one that
is also of course if we go back to the
black box topic, one that you don't really see them
right again, you're interacting with something where the system is
completely hidden from you, so you don't see why things
might end up in that state. Yeah, and microphonance, if

(22:09):
we also good why questions? Why are you doing microphoneance?
This is something I can ask a lot these days
because believe it or not, I don't know how you
feel about microphonance if you heard a lot about it,
or on what side of the pandulum you are. But
this is again like the guys are saying, we just
that Microsoft didn't work or was used for everything and

(22:30):
shouldn't be used for everything, totally agreed. Then the other
guys will say, oh, Microsoft was so great, now we
need to do microfondance. We don't know why because of
front and is working great, but we want to do it.
And so I mean also here I have the full spectrum,
would really be eager to know what your opinions are
on this one.

Speaker 2 (22:50):
Well, that's a great segue actually, as we were talking
about things that are gaining popularity. So I have not
really worked with micro front ends. I've worked in a
very heavy micro service environment where we had different back
ends mostly serving one one single front end. But I'd
love to hear more about what is the use case

(23:10):
because I've had pretty big mono repos that are massive
REACT projects, so I could see if you could break
that up that would possibly be useful. But I'd love
to hear more about how this came about and your
experiences with it. And TJ, I don't know if you've
ever worked with microfrinends.

Speaker 6 (23:30):
Either similar experience. I've got it back in with micros
or a background with micro services, but never really had
a use case for a micro fun end. So maybe
maybe a good place to start it. Maybe you could
just give us like the very simple like one oh one,
what is the micro fun end?

Speaker 5 (23:49):
Why would you use it? That sort of thing?

Speaker 4 (23:51):
Yeah, Or I tell microphone is all about distributing the
work on a front end application, and there are various
ways to do it, which is where the complexity already
comes into play here. So you could, for instance, do
what to just describe as a mono report. You could
do that. You could say, okay, we just now make
certain libraries, let's say component libraries for instance, and in

(24:14):
order to let they have it's still all together. We
have them in a MONORAPO, and we have one large
build that could certainly justify let's say, or it could
be counted as a micro front them. But then we
still have maybe large or longer bill times. Let's say,
we still have maybe conflicting full requests, and we still
need to give everyone access to this. Plus of course,

(24:35):
yeah cd I already mentioned along build times. Now everyone
of course shares the same build pipeline, which means this
is always let's say the one bottle neck potentially, and
so there are of course other ways. So one way
is to say, okay, instead of having real micro services,
we now have micro web servers so to speak, so

(24:57):
servers that still are there, but instead of serving for instance, Jason,
they may still do, they now serve also HTML. And
then we combine these things, for instance on a reverse proxy,
so we have one like an API gateway in front
of it that now takes these different HTML fragments, puts

(25:18):
them together, spits it out. Challenge here is of course,
how do you now debuct this? You're responsible of one
of these fragments, how do you get that? And who's
responsible for let's say, maintaining that reverse proxy or this?
That's good, call it microfront and gateway. The area where
I'm mostly working is in the third one, where you say, oh,
what you can do is you still may have something

(25:40):
like these component lips, but instead of needing a build
process with tooling like webpag or another bundler, you deploy
them independently in form of still javascripts for instance, and
now you combine them in the front and are There
are a couple of popular approaches. Usually what you do
here is, of course you have in a single page
eptic and sometimes people call it in a single page

(26:02):
application of single page applications, because each of these javascripts
can be independent single page application. I'm not really into
that one, but nevertheless you can can, of course refer
to it. The gist of it is that you need
some orchestration engine now in the front ends that runs
in your browser, on your web app, and that can
handle now getting these different javascripts and bringing them together,

(26:24):
isolating them as well as possible. Even though I mean
there are limits. Of course, in document object models, if
you want the true isolation, only way to do it
is an eye frame, which is problematic for a couple
of reasons. Then of course we have the web components
here in this space. They allow us at least to
have proper style isolation, which is great and can be
also not se great. My opinion is for a partier,

(26:48):
but we still have from the scripting perspective a lot
of potential conflicts. And then we can also do something
like yeah, standard script injection with ESMs or UMD modules
and hear things like single spar or the framework where
eye contribute to which is called viral. They help you
to use that as an orchestration engine. So in the end,

(27:09):
it's really about that you allow different teams to work
on the same application even though they have their own repository,
own CD pipeline right, which allows to ship new updates
off their code or a new feature in really seconds
to minutes depending how it is all set up, instead
of waiting longer and maybe having more loaded processes sharing things.

(27:31):
So this is what it is about, a little bit
like in the micro service department. Also here you often
here hear one argument you can now use independent technology.
So one team uses React, another users Anglar. Well, let's
not go there, right. Personally, I would say you should
try to have a set of core technologies because it's

(27:52):
the front and if you combine it in the front
and in the browser, right, you ship all that to
users browser. And if you suddenly run ten frameworks in
this yeah, maybe on a mobile device, it will not
be a great experience, right, So you should maybe try
to limit it to one. Or maybe there's this other
cool framework that's used in a particular page or particular

(28:13):
part of your page, maybe you should try to limit it.
But I guess it's the same again as with micro
services that the goal was also never to have a
patchwork of technology. It was always to just you know,
allow using different technologies. That then the best thing, the
best tool for the job. If you have their service
that deals a lot with it, I don't know, data manipulation,
you can use a language or framework that's dedicated to that.

(28:35):
If you have another service that I don't know, should
do something else, and you have a team that only
knows I don't know, c sharp dot net, they can
use this this one And I guess it's similar here right,
so you shouldn't. Just because you can doesn't mean you should.
But yeah, it gives you a little bit more freedom.
And this is what microphone is about, giving you this
freeedom to actually, yeah, I have distributed developments possible and

(29:00):
be a little both or flexible and agent as we are.
But there are, of course, maybe that's a good transition.
There of course counter arguments too, right, So complexity rises
just that two and you need somehow to Yeah, I
have this orchestration there under control. You also need new
processes because yeah, now teams can maybe deploy independently. Maybe

(29:22):
you don't want that, maybe you want that. It always depends,
and so you always of course also hear shift complexity, right,
So you gain something, but then something else is maybe
a little bit worse or challenging for no silver bubllets.

Speaker 2 (29:36):
Kah.

Speaker 6 (29:36):
Well, no, it's interesting because I'm thinking like so it
helps my brain to think in terms of like concrete examples.
So I imagine I'm building my standard react app, but
I have a shop, and the shop is quite a
bit different, and so today, because my brain doesn't think
in terms of micro friend ends, I would think like, oh, okay,
my shop is quite a bit different, So I'm going

(29:57):
to want to do my best to make sure I'm
like lazy loading that or like deferring loading of that.
But I would still my gut would still be like, oh, well,
of course i'd keep that apart of my same React application, right,
I just make sure to try to do my best
to lazily load this stuff in. It sounds like the
micro front end approach would essentially say that shop would

(30:18):
be almost like its own separate project in a sense. Right,
that it would that there's some like like you said,
orchestration layer that figures out how to bring that app
in and reconcile it. So first of all, I'm curious
if my understanding of this is correct, and then I'm
also trying to get like sounds like the benefits of

(30:40):
this is it's because it's like it's isolated thing, then
the team that's working on it can kind of work
on it potentially even like deploy it without worrying about
the rest of the app. Like, if you're we assume
the rest of our React app is quite large, it
probably would take forever to build and test and deploy,
and having like little logical sections of these isolated I
could see some benefits of that, but like you said,

(31:01):
I could also see trade off. So I guess, first
of all, is my understanding of this correct, Is that
use case sort of makes sense?

Speaker 4 (31:06):
Yeah, it makes We've got in the shop most I mean,
there are a lot of e commerce companies that use
micro fundance. Most of them, however, don't do client side
what we call client SiGe compositions. So where we already
ship a JavaScript that acts as the orchestration layer and
then brings together the other script, most of these companies
actually do the server side composition here. The reason is that,

(31:30):
first of all, their parts are not really so much
about interactivity. Second, they care a lot about performance, so
that they really want to have something that can be
pre cash and so on, and they just send it
out to the end user that it's as fast as possible, right,
so they followed this, one hundred million seconds of additional
loading time means that less revenue, and so they always

(31:51):
try to optimize here. But nevertheless, there are of course
also e commerce shops that are built using microfundant, using
a microphonat approach, and for that, yeah, so what you
would do usually, but there'll of course a lot of
different approaches, but what I personally like as an approach
is that you follow here a more domain chrythm approach.
So what you would want to do is you identify

(32:14):
first of all the grand theme of your applications. Well
it's in the e commerce space, right, But then you
start identifying subdomains here, right. So one subdomain could be
I don't know a recommendation model. So you're on a
product detailt page. You want to see a list of
recommendations related products I don't know, products that may only
make sense for this particular user, and so there could

(32:34):
be one team just working on let's say you I
fragment for that. This team may also want to bring
in I don't know something now menu bar or in
some menus here that that we offer, and we may
have another team that only works on maybe the product
details page. There may be a third team working just
on the product search. And product search is also interesting
because while it may have a dedicated page right search

(32:56):
resultants on, it also has of course maybe a search
that's always visible and they own this spar right, so
every input and so on that's owned by this one team,
and so you would actually not just one screen and
say this one screen belongs to this one team, but
you would actually do it. Well, I actually decompose every
screen that I have, and maybe I have the main

(33:17):
content of this screen that goes into particular team, but
then I see other components that may be on a
lot of pages, maybe all pages, may only be in
a few pages, but I identify in what's the main
does this fragment of your eye lie? And this is
what microphons are about, that you cannot find the correct
team that only let's say, ear is now the search
the search bar and the search page, the search without page,

(33:40):
and they will do everything with it, and then if
there have an improvement for the page, they can ship
it completely independently and they are just responsible for that.
There are also approaches out there, I mean one that
is certainly easier to implement, but in my opinion, will
lead to well, let's say more frustration team where you

(34:00):
divide the UI by what you see on the screen.
So you just say, oh, there's a head up, that
should be a microphonet, there's a food, should be another
microphone in, there's a navigation bars should be a third microphoneant, Yeah,
you see that. It are quite a lot of beginner tutorials.
In my opinion, it's there because it of course makes
sense visually and it's easy to implement, I mean easier maybe.

(34:21):
But on the other hand, of course it will have
a lot of frustration points because suddenly this team that's
doing in navigation bar is always let's say, dragged and
pulled by every other team. We need something in here
under this condition, we need it. Can you just update
that we have a new icon and it will never
work out smoothly? I mean you just created now Yeah.
I don't know if there's a word for it, maybe

(34:43):
spaghetti modulet I don't know. Yes, we can, we can,
we can invent something now here, but but it's really
it will not be maintainable in my experience, and so
I always advocate going for the identifying domains and putting
those into let's say teams or microphondance, which are then
responsible or in charge. Yeah, certain teams are in charge

(35:06):
of them.

Speaker 2 (35:06):
That's what I was going to ask is how do
you do you have any advice for how to know
when a project has gotten so big or something a
piece of a project is so complex that it should
be broken out because it seems like that's a very
that might be a very difficult thing to identify. When

(35:26):
when is the right time to break this into its
own separate front.

Speaker 4 (35:30):
End the good question.

Speaker 3 (35:33):
It depends.

Speaker 4 (35:35):
I always say, if you're happy with your monoliths, don't
change it. I mean there's a reason for it. Also,
I mean we started with the monorepple, right, and I
said mono repo. It can also be something like a
microphone introdutionally, just now combined to different pieces of build time,
which is also fine. Right, So if you start with
a monorepple, for instance, if you say, I don't know

(35:56):
if they ever need this micro front and stuff, but
it would be nice to architecturally maybe group it, my
advice would always be, well, start with a monolith, but
do it as a mono report, because if you did that,
it will be easy later on to just extract out
certain modules and just put a little bit of with
the right framework debugging and seedra capabilities on it, and
you then have your distributed microphone and solution. But you

(36:19):
don't need to start with it immediately because that adds
just complexity at a stage where all you should care
about is really bring out your stuff and see that
it works. But nevertheless, so when it's the right time
to let's say, make the transition, well, I would say
if the majority of the team members are unhappy, that's
always a good time because if frustration grows, I mean,

(36:40):
you suddenly have a pain point and you need to
solve that pain point. People wouldn't be let's say, in pain.
If they would say, oh, we ship features too fast, well,
it's too much fun. We can experiment around this new stuff. Well,
that death doesn't sound like pain to me. But if
they say, oh, my poor regress is hanging there for
two weeks and we were supposed to shift that feature
a month ago, but suddenly all the bills take so long,

(37:01):
and then there was this conflict here. In conflict there, well,
it sounds like some things he needs to change somewhere.
I'm not sure if microphone is is a solution here, right,
but I'm sure that something needs to change, and maybe
microphone isn't a good solution if you hear as pain points,
especially things like it needs to go faster particular features.
So this is really where microphones may hit the nailia.

(37:24):
But make no mistake, migration of existing applications I mean,
if we have this case that it just describes monoapo
all nicely grouped this, this is the beauty. This will work.
But usually it's not as nice like this because the
application is five years old. It started nice, but then
duct taper duc Tapier there was a feature that never

(37:44):
someone thought us, so we needed to work around for it.
How can we now do that in this distecret world.
It will not be a pretty journey. I mean, certainly
the architecture will be more sound afterwards, and most time
will not be spent in this microphone in space, but
rather in how can we distributed? Because we've made it
a smucketti before it. But certainly I think this is

(38:04):
when you hear enough people complaining, it's a good point
to think about it.

Speaker 6 (38:08):
Yeah, Honestly, the productivity and the sort of flexibility around
this seems like the biggest advantage to me because I've
certainly been on teams and been in projects where it's
like you put it in terms of happiness, but it's
almost in terms of just like how how evil you
are to get stuff done? Because countless times where like
you go to deploy something and it's like, oh no,

(38:30):
we can't put the push this out because this is
in the way, or no, this is tied to this
really so that's not ready.

Speaker 5 (38:36):
We have to back this out.

Speaker 6 (38:37):
We have to bring in the person who's really good
at get to figure out how to reconcile all of
these problems, right, and you keep stepping on each other's toes,
and nobody wants that to be their day at work,
like you want to be shipping things, doing things, and
software just being a complicated topic. I think as projects grow,
as we work on bigger and bigger things, there's something

(38:59):
in here about that sort of stuff getting in your way.
So it's an interesting way of bringing it out because
as you described it, you're talking far more granular components
than I had like pictured in my head because again,
like I went, I immediately went to like, oh, my
entire shopping experience, but you're talking like just even like
individual widgets like the search or the products thing, and

(39:21):
it's it just goes to show how like my mind
does not work this way just because I haven't been
a I haven't really considered this. So now like I
used to like retrain my brain to like when I
see things like that, to think, oh, like that's that's
an option or that's a potential way that I can
attack this.

Speaker 4 (39:38):
Yeah, I mean it takes. I mean I'm not working
in this now for already more than five years in
the microphoneance space. So when I thought it was just
the well the term microphone and wasn't well existing yet,
they later on I think it first came up in
the salt Works radar. I don't even know. Someone taught
me while ago that it was first point. But anyway,

(39:59):
that was then coined afterwards, just retrospectively, I was like, ah,
that's what That's what I was doing. Right either way,
I mean that you don't start with that right away.
And still, of course getting the rights decomposition right on
this domain that I described is also not easy, right,
so you need, of course do main experts. You need
to know people of course that really understands the requirements

(40:22):
of your solution that you either want to build or
that you have built and I want to let's say
roll out as microphone then and yeah, you need of
course to then train the people. Ideally, of course, this
is the experience I had in most projects. I mean,
if the micro frontum setup was done well, developers of
individual modules don't even let's say, know that they are

(40:44):
doing micro fundams. I mean they're just developing. I mean
you tell them you now do the shopping basket, okay,
and then they develop ideally at least now this client
site perdigon like for a single page application. They even
have the debugging experience the same as you know, as
if you would debug the grand application right on. The

(41:05):
difference is in their view, they only see let's say,
naked application. Maybe I don't know how to food are
in there, some design elements and they're they're saying that
they are focusing on and all the other microphones may
not even be there. Maybe they are there. I don't
know they've used in but you can decide it in
the setup for instance. And so they don't even know.
They're just developed there and they don't need to know
the particularities of this kind of style. And I think

(41:28):
this is a good way, because we're back at the
black box. I guess here, if you would now know
a lot of stuff, or need to know all this
stuff what's happening below, I mean certainly would be great
and in certain edge case conditions it would help you.
No questions are But in the ninety ninety five percent case, right,
I mean if the platform with the run time or

(41:49):
it takes away all that for you, and all you
need to do is focus on your problem and how
you solve that. No technological questions asked, No, oh oh ah,
I need to wire up this with that. No, you
just focus on your domain specific problem. This is where
I want to be because at the end, I mean,
this is also where for instance, our case, we are
getting the money from our customer doesn't say we're paying

(42:10):
you to debuct react. No, we're paying you to bring
the shopping cards to life, for instance. And I think
this is working in your problem. I think this is
what makes some frameworks productive and great, and others well
technological interesting, but otherwise maybe not the productive.

Speaker 2 (42:31):
So are these the kinds of things? And I'm sure
much more that you talk about in your book that
you just wrote.

Speaker 4 (42:38):
Yeah, the book is, I would say, well, let's be
just end in the camera. It's called The Art of Microfondance.
You can find an Amazon. It's released from the Pucked
Publishing company, and half of the book is very practical.
So there I mentioned, let's say the three grant schemes
that we have in a microphonance space right, built time,

(42:59):
in service side, client side. These are all covered in here.
Class of course, a lot more patterns, so there's a
lot of also here a lot of shades of prey, right,
so I think it has seven patterns and all of
these very practically introduced. But most of the or let's say,
the other half of the book really deals that with

(43:21):
how do I choose the right to maintain composition? How
do I now work with designers for instance, because they
will still design a monolith and you need to teach
them what are you doing technically that they will well
give you the best experience because at the end of
the day you will design, you will create something that
is in its mature flexible. So for instance, the navigation bar,

(43:42):
it's not cut in stone. Someone can just write a
new feature and they have a new item. How does
it behave in under these conditions? Right, So suddenly designers
need to go beyond the static screen design and really
think about these things, but also about organizational changes, because yeah,
if you really distribute the code, suddenly responsibility should be
also distributed and things like that. So it's really half

(44:04):
and half, so one half very very practical. The other
half I would still say practical, but maybe not for
the let's say standard developer more let's say for architects
or decision makers than and people to say, oh, I
now want to know what what is beyond the horizon
if we go that way. Yeah, and certainly is one
of the things I covered.

Speaker 5 (44:26):
He and it's got a five star average on Amazon,
so I mean.

Speaker 4 (44:32):
It's a lot of small numbers. So I wouldn't say
it's dead.

Speaker 5 (44:36):
You've got to market it, sell the bush.

Speaker 4 (44:44):
Sorry, Yeah, I didn't want to just spoil you, and
I always try to be honest. So at the moment, mean,
the book is fresh one month out there, so I
don't know how many reaviions it now has on Amazon.
Common on the German side has I think two reviews
for three I don't know anyway all five starts at
the moment. It will not stay that way, so I'm

(45:05):
I'm a realist in that case. But still it would
be happy if any guy, any any girl once say
well look at that. Just also you can give me,
let's say, a message on Twitter for instance, because I
still have I think fifteen or twenty five percent of
the ebook, and there may be a chance. I still
have I think some physical copies, so hard copies of

(45:27):
this that's like the one I old man that I
could get you for free actually if you message me.
But these are limited. Actually I think I have five
or six left there. But anyway, if you're interested, always
just taking me. I'm very open, of course, and sorry,
I want to sell the book more. It's the best together.
It even discusses west development in general in the introduction.

(45:48):
You should read it. If you don't know what cgi
SSI and so on, it's in there. If we talked
about tooling web peg parcel, it's all disgusting here. Why
that's to new? That's not in this book at I think.
But I even have ees building here, so you can't say,
I'm yeah, there's still pretty new stuff in here. Could

(46:10):
be on the computing stuff. But anyway, any kind of
criticism also to me, right, So if there is something
you like to improved, I don't know if there will
ever be a second edition, but just tell me. I
always also love to learn. And yeah, I'm not saying
the book is perfect, but I try to put everything
I know about my performance in there, even though as
always right, you finish the book when you're like, hmm,

(46:32):
this is one cool thing. I didn't mention it, but
then I just make a blog post about it and then.

Speaker 3 (46:42):
Well that's fantastic.

Speaker 2 (46:43):
So Florian, as we were talking about, if people want
to get in touch with you about your book or
about anything else, what are the best ways to reach you, I.

Speaker 4 (46:51):
Guess the best way is Twitter. They might handle the
flow and rubble just one word. Maybe we'll have the
address also in there. Otherwise, I'm of course on guit
ub some of the projects I'm contributing there to Guita,
So this is a chetroom. For instance. I'm very active
in the Piral chatroom, so if you're interested in a

(47:11):
microphone and framework PIRL, I will also paste the address
in there. Would we want to check out? And we
have their public guitar chatroom. I'm very active there. You
will see me chatting around giving answers to Pyrol in
particular or microphones in general. And I think we have
a great community in our channel. We have I don't know,
one hundred and sixty one hundred and seventy people, not

(47:35):
all of course active all day, but there's always one
good answer for every question. And I will paste it
in the chatroom. But that's either I guess that's the
best way to reach me. Otherwise, of course email can
give you this and otherwise on my personal website. They're
also all the I mean, I'm also in Skype and

(47:55):
so on. All the messengers rights in a Richmond which one. Yeah,
it's like it this comic about all the stand ups, right,
So there are certain stand ups we need to imprace
them all. We need a new one. It's the same thing,
so we need a messenger to have all the messengers.

Speaker 3 (48:17):
Very good, excellent.

Speaker 2 (48:19):
Well, now is a portion of the show where we
move into picks. So TJ, would you like to start
us off this week?

Speaker 6 (48:26):
Yeah, I'm going to pick some Marvel stuff. So I
went to the theater for the first time and since COVID,
which honestly was probably the best part of the experience.
It was just really I didn't realize I'm not a
big movie person. I didn't realize how much I sort
of missed the atmosphere of this actually going seeing a
movie in person. And we saw Black Widow. It was

(48:47):
pretty good. We definitely enjoyed it. But it's set off.

Speaker 5 (48:52):
Now we have to watch all the Marvel things.

Speaker 6 (48:54):
So now we've been on Disney Plus and started WandaVision,
which was it' quite the trip, like, very very engaging
and very interesting show. So highly recommend, I guess go
to if you can safely go to a movie theater. Now,
i'd recommend getting back to that. And WandaVision has been
a pretty good show that sounds like a good re

(49:15):
entrance to the movies. Marvel movies very rarely disappoint me.

Speaker 5 (49:19):
Yeah.

Speaker 4 (49:20):
Nice.

Speaker 2 (49:22):
Well, my pick this week is going to be totally unrelated.
It is a GitHub course that I found, or I
guess GitHub documentation and it's called IoT for Beginners, and
it's actually made by Microsoft. But if you've listened to
the show with any regularity, you'll know that I started
a new job about a month ago now, and the job,

(49:44):
while it is web development, it is working for a
company that specializes in Internet of Technology enablement called blues Wireless,
and so we make things called note cards that connect
to Raspberry pies or are we knows, or to just
the cloud by themselves. And so I need to actually

(50:05):
understand how the Internet of Things works because I've never
really interacted with it before. So I'm starting with some
of the really basic online things that are available to
kind of learn how to use raspberry pies and get
into that sort of space. And this IoT for beginners
is very comprehensive. It's free, there's videos, there's build kits

(50:30):
that they recommend, there's all kinds of really useful getting
started from the very basics, and I'm really enjoying it,
So I would recommend that for anybody who's kind of
looking for a foray into it. So, Florian, do you
have anything that you'd like to pick?

Speaker 4 (50:46):
Well, I mean, first of all, well those are all
good picks. Black Widow. I still want to see I've seen.
I can also stream it. It's the twenty euros quite
expensive actually for the extreaming access there. But anyway, one division,
I yeah, I've seen the first two episodes. It was
crazy for me. I don't know.

Speaker 6 (51:06):
I actually you have to stick with it because it
starts absolutely insane and then they start to somewhat explain it.

Speaker 4 (51:14):
But then I heard it got better, but I mean
they lost me. Anyway. The Microsoft things, they're always greater.
I remember when Microsoft release, for instance, the clouds patterns
that was really great. So they always do a great
job at documentation and being really comprehensive, really accessible and approachable,
so that that it certainly kick out. I need to
check that out. So my pig would be a book

(51:35):
and all good. But I mean that's for me, is
like a hidden classic which is called I don't know
your code as a crime scene. It's, yeah, an interesting
book in that fact that sometimes I mean already things
like for instance we heard about GIT here leave trails
where you can see where the problems are in your

(51:55):
code base. So for instance, if you see that let's
say a certain amount of commit is always in a
part of your application with a certain file, let's say that
usually doesn't carry any feature, but you know it's just
for instance, some orchestration lays. Then you know architecturally something
isn't dry because after a while, I mean, it should
stabilize pretty much, and you should just see for instance

(52:18):
changes in well, new files being added, new features coming along.
And if you see a pattern like that, well you
have a very healthy application. Congratulations. Usually, especially in our
own applications, I see a lot of commits happening to
files where well they should be already stable somehow. But
either I'm just in refectory mood or really something is
not really done right. And I mean, this book goes

(52:39):
into a lot of patterns of detecting such fishy things.
What you can do then and well, yeah, following then
your crimes to detect what to improve, because after all,
we shouldn't just reflector for the refectory sake, but we
should reflect them and make things more productive. But for
that's the first to recognize what's all making us not
so abductive. This book is I think, at least for

(53:02):
me it was and still is when I haven't opened
it a great guide. Today I will post an Amazon
link for it.

Speaker 3 (53:09):
Excellent.

Speaker 2 (53:09):
That sounds like a really good read and something that
I will definitely be looking into. I'm always looking for
new ways to improve my own coding practices. Well, Florian,
it has been an absolute pleasure to have you on.
Thank you so much for joining us today on React
Around Up.

Speaker 4 (53:25):
Thanks for having me was a pleasure, all right.

Speaker 2 (53:28):
We will see everybody on the next episode.