June 4, 2024 • 24 mins
This week, guest host Ben Lloyd Pearson chats with Thayse Onofrio, Software Engineer at Clutch and ex Thoughtworks. Thayse discusses how micro frontends allow individual application components to be operated and deployed independently, helping teams avoid the complexities of a monolithic architecture. They cover the technicalities, challenges, and advantages of implementing micro frontends, including the importance of module federation and proper coordination among developer teams. Learn about the future of frontend development, the cultural impacts, and the best practices from Thayse’s experience.
Episode highlights:
01:02 What is a micro frontend?
04:08 Building from scratch vs. out-of-the-box solutions
10:30 What’s the process for moving to a more micro frontend based approach?
15:46 What changes do you need to use a micro frontend framework?
17:28 What does a team using micro frontends benefit from once it's all set up?
Show Notes:
- Thayse Onofrio | Twitter
- Thayse Onofrio | Substack
- Thayse Onofrio | LinkedIn
- Thayse Onofrio | LeadDev
- Software Engineering Intelligence: Exposed & In Action
Support the show:
- Subscribe to our Substack
- Leave us a review
- Subscribe on YouTube
- Follow us on Twitter or LinkedIn
Offers:
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Thayse Onofrio (00:00):
If the developers are not comfortable
(00:01):
with the technical side of it,they don't know much about it,
they might have some concernsinitially.
So, I would say that's more likea challenge, just making
everyone feel comfortable withthat as they go along.
But outside of that, I thinkfolks are generally happy about
just having this independenceand ownership.
Ben Lloyd Pearson (00:20):
So you heard it here, do micro frontends,
your developers will be happy.
How can you drive developerproductivity, lower costs and
deliver better products?
On June 20th and 27th LinearB ishosting a workshop that explores
the software engineeringintelligence category.
We'll showcase how data-driveninsights and innovative workflow
automations can optimize yoursoftware delivery practices.
(00:44):
At the end of the workshop,you'll leave with a
complimentary Gartner marketguide to software engineering,
intelligence, and otherresources to help you get
started.
Head to the show notes orLinearB dot IO slash events to
sign up today.
Hey everyone.
Welcome back to Dev Interrupted.
I'm Ben Lloyd Pearson.
I'm the Director of developer rerelations at Linear B.
I'm pleased to be joined by ThaeFerro, uh, the lead software
(01:07):
engineer at ThoughtWorks.
Thae, thanks for being here.
Thayse Onofrio (01:10):
Thank you.
Thank you for having me.
Very happy to be here.
Ben Lloyd Pearson (01:13):
Yeah, wonderful.
I, we, we were talking, we had along trip from Brazil, so glad
you made it here So.
So, we're going to talk a littlebit about the session that you
have here at this event.
But, you know, I'm sure we'lltouch on other subjects too.
But, you know, the main thing isthat, you know, as apps expand,
that are needed to manage thevarious functionalities.
(01:33):
And without the rightinfrastructure, you know, this
growth can lead to a host ofissues from communication
challenges and code conflicts tobusy pipelines, tangled release
interdependencies.
It can be a pretty complexpicture, and your talk is all
about the solution you've comeup with, which is micro front
ends.
And this architectural approachhas allowed individual
(01:56):
application components to beoperated and deployed
independently to sort of get outof that like monolithic maze
that a lot of companies arefacing.
So I want to talk about, youknow, what the future of
frontend development looks likewithin this context.
But before we get into that,let's just get into the basics.
So what is a micro frontend?
Thayse Onofrio (02:20):
Very much related to microservices, what
is more popular.
Uh, but the same way microfrontends, we have like smaller
frontend applications, but wecan develop and deploy them
independently from each other.
Each having their ownresponsibilities, but then they
all look the same for the user.
So, as a user looking at thisapplication like if it's a web
(02:41):
application, it doesn't reallymatter to me how they are, how
it's done, how everything wascreated.
Uh, but When we look into howit's being done, developed,
deployed, everything isseparate.
And we just compose themtogether.
So for a user it shouldn'treally matter, but for the teams
working on it, it makes a lot ofdifference.
If it's not like a wholemonolith and we can work on our
(03:04):
own thing without having so manyconflicts and blocking each
other all the time.
Ben Lloyd Pearson (03:08):
Awesome, awesome.
So, so let's, let's talk aboutsome of the unique challenges
that you've encountered whiledoing this, uh, cause, you know,
uh, you know, I like thecomparison to microservices,
that, that, like, that concepthas been around for a little
while, so people are, are prettyfamiliar with it.
What are the unique challengesthat you've faced while you've
been implementing this microfrontend?
Practice, specifically relatedto like the monolithic
(03:30):
architecture.
Thayse Onofrio (03:31):
Yeah, I think with monolith architecture,
especially when the teams startgrowing too much, we can get a
lot of, uh, conflicts.
And if you have different teamsworking on the same code base,
it But maybe even differentproducts.
It can be very confusing foreveryone working on it.
Uh, that needs to be a lot ofcommunication within everyone.
(03:52):
And that doesn't happen if youhave separate teams.
Even in the same team, sometimesthere is not enough
communication happening.
Uh, so we start to facing a lotof issues if we are using the
same pipelines, like thepipelines are always busy, there
is no enough resource to handleit.
So, it starts to get reallychallenging and I think one of
the most pain points isdeployment because you have to,
(04:15):
one team depends on the otherteam to do a deployment, so you
don't have that, um, flexibilityabout just being able to deploy
whatever you want, uh, it canreally slow the team down,
having to depend one team on theother.
So I think that's where, and alot of times, going towards this
micro front end approach reallyhelps.
Thanks.
And then we can, and there are alot of different techniques we
(04:37):
can use to get to this approach.
Uh, but yeah, I think definitelylooking into that and seeing
what makes more sense for yourteam.
And depending on the tech stackthat the team is comfortable
with as well, uh, you can findan approach that you can start
like slowly going towards thisand separating things out as
much as possible.
That brings a lot of benefits, Ibelieve, to the teams.
Ben Lloyd Pearson (04:59):
Let's dig a little bit into the technical
side of this.
Have you been relying mostly onlike out of the box solutions or
existing, libraries that are outthere?
Or did you have to build a lotof this yourself, like from
scratch?
Thayse Onofrio (05:10):
Yeah, I think now there is a lot of options.
Uh, I think previously mostlydoing that on the server side.
Uh, but now we have, and I willtalk on my talk as well a lot
about using module federation,uh, which uses Webpack to do it.
Uh, so it's way simpler becausenow a lot of front end teams are
already using Webpack,everything, like you already
(05:30):
have everything configured, youjust need to add a new plugin
to, to use module federation.
So that really helps.
But yeah, I think there are manymore solutions now, it's
becoming more popular.
It's easier to get started, Iwould say, for most teams that
are already using a lot of thosetechnologies.
Ben Lloyd Pearson (05:49):
So, you know, you know, in, in front line,
front end libraries inparticular, you know, I feel
like that's a, that's an area oftechnology that has just, I
mean, it's, it's become a memejust how many different
libraries and services are outthere.
I see all these posts on, onsocial media about how there's
too many of them and how, uh,you know, when everything is
like working together and sortof like the golden package, it
(06:11):
can be great, but the momentyou, you try to like, Breakout
of the, like the, the cookiecutter formats, um, particularly
with JavaScript.
Um, that, you know, it can getpretty difficult, you know,
cause there's, I mean, there'shundreds, maybe even thousands
of libraries that you can choosefrom out there.
So I'm, I'm wondering, you know,how did this complexity affect
your ability?
Like, did, did you have tochange how you approached the
(06:33):
challenge?
Were, were there specific groupsof libraries that you found
beneficial, you know, just ingeneral, like, what kind of
challenges does that, thatcomplexity of just how many
options are present?
Thayse Onofrio (06:45):
That's a great question.
I think a lot of people actuallysay that one of the benefits of
using micro frontends is thateach, uh, micro frontend that
you have can have their own texttag.
So you can choose to do thisfrontend in one library, this
other using another library, andthen you just kind of stitch
everything together.
That's possible, that works, butI wouldn't recommend it.
(07:09):
So, if you are looking at thesame view and you are loading,
like, just as a user going to aweb page, I would have to
download a bunch of libraries,dependencies that not really
needed, and that can reallybecome complex to manage and
really affect the performance.
So, it's that kind of thing thatit's possible, but that doesn't
(07:29):
mean you should do it.
And, yeah, and even if, ifyou're using the same, uh,
libraries, you have to becareful about versioning.
If you have, like, differentfrontends in different versions
of, of those libraries, how willthey interact once you are
composing them together?
So that's, that's a big concern,I would say, with using micro
frontends as well.
Just being careful with using somany different libraries.
(07:53):
There needs to be, like thesystem needs to work together
also.
You need to have a lot ofcoordination between the micro
front ends in a lot of ways.
And I think dependencies is oneof them.
Ben Lloyd Pearson (08:03):
Yeah.
So do you, do you give teamslike a lot of leeway to sort of
build that or define that paththemselves?
Or do you rely more on sort oflike, do you give developer
teams like, like solutions or,or guidance on this?
Or do you let them kind ofchoose their own path more?
Thayse Onofrio (08:20):
Yeah, I think there needs to be a lot of,
coordination in that in a sense,and, I think it's a bit
challenging because you do wantthe teams to have their own
freedom of choosing what path tofollow, but there needs to be
some kind of, uh, governancearound it.
So I think it really depends oneach context and each team, but
(08:41):
usually having someone that canat least set the, uh,
Guidelines, set some, uh,guardrails around it really
helps.
So you avoid like having oneteam going completely different
way than the other and thencreating those complex
challenges.
Uh, so yeah, just having a forumfor the teams to talk about it
as well really helps, but Iwould say just setting
(09:03):
guidelines and, uh, I think alot of teams also use these,
templates to get started as, asa micro frontend.
So you have like some librariesthere.
You have some.
Guidelines that are automatedalready to get started.
So at least teams get started inthe same direction, you know.
Ben Lloyd Pearson (09:21):
So, one other thing that, uh, you mentioned,
uh, or you mentioned in your,your talk is, uh, uh, some of
the complexities around buildpipelines.
So, so, you know, a monolith canha is typically going to have
very different buildrequirements from a, you know,
front end microservice.
So, how has that played intothis, uh, into this equation
(09:43):
and, you know, what sort of,what sort of things have you had
to do to, to overcome challengeswith that?
Thayse Onofrio (09:48):
When we are in a monolith approach, the pipeline,
uh, when we need to handleeverything related to that, so
we can become challenging.
And then when we start to breakdown each front end monolith,
micro front end actually, willhave its own, uh, build pipeline
so you can build and deploy codeindependently from each other.
But I think it really helps thatyou can add the sort of
(10:11):
validations that you need basedon that specific framework.
Um, piece of, uh, microfrontend, which doesn't
necessarily is the same as theother.
So you can really adapt that andmake sure that you are having
the right validations, you arebuilding code the right way for
that specific piece of code andgetting that into production.
(10:31):
Uh, so yeah, I think it justgives a lot more flexibility.
So each team can do what'sneeded for their own challenges.
Ben Lloyd Pearson (10:39):
Gotcha.
And it seems to be like that's abig theme with rolling this out.
How many developers do you haveat your organization?
Thayse Onofrio (10:48):
It really depends on the teams that I'm
working with as a consultancy.
It changes a lot, but I thinkthe last time I was working with
this, in my specific team, Ithink we were around eight
people.
Ben Lloyd Pearson (11:00):
Okay, okay, gotcha, yeah.
Because I just know when thingsget big and complicated in the
developers world, like, uh, youknow, it is great to offer like
a lot of those, um, liketemplates effectively that sort
of set them in the rightdirection.
But there's always just so muchnuance to the technologies, to
the processes those teams use.
(11:21):
So I'm wondering what, what'syour What does it take to
migrate, you know, what, fromthis like monolithic design to
one where, uh, you're doing moremicro frontend, maybe even some
microservices, you know what,what's step one?
What's, what do you do afterthat?
Like, is there, is there apredictable progression or, um,
is it more nuanced than that?
Thayse Onofrio (11:41):
Yeah.
I would say that the initialthing, and one of the most
challenges part is understandinghow you are going to do that in
terms of.
Which parts of the applicationcan be separate modules, how
you're going to break thingsapart.
So thinking about boundedcontext and how do you get to
that approach of knowing thisshould be a separate module,
(12:03):
this other thing should be itsown module.
So I think that's the most scarypart in the beginning, trying to
do the right thing, because atthe same time that you want to
get all the benefits ofSeparating things out, you don't
want to get too granular,because otherwise then you are
just adding new challenges andnot really getting the benefits
out of it.
So there needs to be like abalance of where it makes sense
(12:28):
to do it or not, much likemicroservices.
Um, and yeah, if we are able toalign like the microservices
approach with the microfrontends approach, I think we
get a lot of value out of itbecause then we have this one
deployable unit of code.
Uh, and getting all the benefitsfrom, from all of that.
Uh, but I would say, yeah, thefirst thing is understanding
(12:50):
exactly how to do it in terms ofwhich will be the, the physical
and ownership boundaries ofthose micro frontends.
And then you can start lookinginto thinking about the trade
offs, like what, what will bethe benefits added, what will be
the new challenges that we'llget.
Because there is always tradeoffs, always we need to think
about the, the new challenges aswell.
(13:11):
And then I think we can move onto like, choosing the approach,
how we are going to do that, andreally take into consideration
what's the team's knowledge ofthe tech stack as well, so you
can choose an approach thatmakes sense for the team, that
it's not everything new forthem, that they need to learn
everything from the beginning,you know?
So then, after you do that, Ithink you can start actually
(13:32):
doing the migration, andthinking about small steps as
much as possible.
What's the minimal thing thatyou can do that you can start
already to get some value out ofit before you move on to
increasing that.
So doing that as slowly aspossible in a way that we are
not impacting user experience,right?
(13:53):
Because we can't just stopworking in what is live in
production and stop maintainingit, stop adding functionality to
it, just start working onsomething new from scratch.
So we need to find a way to dothat, uh, a little bit more
slowly and.
Starting to get value out ofthese, these changes.
Ben Lloyd Pearson (14:11):
Nice.
So use use a phrase there thatI've never heard before that I
want to dig into a little morebounded context.
that is a, I feel like I shouldknow what that means.
Maybe can you explain a littlemore like what exactly you're
describing there?
Thayse Onofrio (14:25):
Sure.
Yeah.
Uh, so bounded context is aconcept from domain driven
design, DDD.
Uh, so here we are talking aboutthis, uh, finding these
boundaries about like physicaland ownership boundaries.
And it really means that eachbounded context should be an
independent service, and in thiscase talking about micro
frontends, that should beevolved independently from one
(14:47):
another, so developed andmaintained independently, but
while they should work togetherto create this unified system.
So really what we want toachieve here with micro
frontends, but it's a conceptthat doesn't really need to be
attached to a specific approachlike microservices or micro
frontends.
But I think both of theseapproaches, uh, feed from
(15:10):
bounded context and, and DDD inthat sense.
Ben Lloyd Pearson (15:13):
So, it, it, because it, it kind of sounds
like this is, like, kind of acritical aspect of understanding
where to, like, where to begineffectively.
It's like, where, where can youpick a part of your UI that you
can just pull out and make thatyour first, like, microservice.
So, for an organization that islike, wow, this sounds amazing,
I want to do this.
Like, like, how do they findthat first?
Thayse Onofrio (15:38):
That's definitely, I think, very
challenging, and I think itreally helps to think about the
user flow, like how the userinteracts with your page, so you
can start to think about, whatis the flow that the user is
doing here.
And you kind of start seeingthat the user is going to focus
on one specific part instead ofthe other.
(15:59):
So you start to see how things,uh, are separate from a user
point of view.
And then you can think about howthat would make sense from the
development, team point of viewas well.
Starting to separate that out.
Um, but yeah, I think using, uh,A lot of those, DDD tools as
well might help.
Uh, I'm not an expert in it, soI'm not going to dive deep into
(16:23):
that, but just studying a littlebit about it, I think it would
really help for someone whowants to start going towards
this and separating things out,trying to think about what
approach you use for that.
Ben Lloyd Pearson (16:35):
Wonderful, wonderful.
So have there, have there beenany sort of, like, cultural
changes that you've had to do,like, in terms of, like, how
people think about how theybuild code or, um, the way they
approach problem solving, uh, asa result of adopting, uh, like a
micro front end framework?
Uh, you know, so beyond, like,the technical challenges and
(16:57):
even the process, like, isthere, is there cultural
challenges that you have toovercome as well from an
engineering perspective?
Thayse Onofrio (17:05):
Great question.
Yeah, I think mostly teams aremore, are usually happy, you
know, about being able to havemore ownership about their own
things.
Not having to rely so much onother teams and other folks.
Uh, and just, yeah, having moreindependence in that way.
So I don't think there is somuch cultural challenge.
I think It's more like
Ben Lloyd Pearson (17:26):
opportunity, right?
It, it's like you're, it's a wayto empower developers while also
giving them a framework to be alittle bit safer.
Mm-Hmm.
you know, uh, have a little lessrisk.
I imagine.
So, yeah, I mean that's, that'sactually a great point I think
is that this is a great way tomake, to encourage your
developers to be a part of apositive cultural change, you
(17:47):
know?
Yes,
Thayse Onofrio (17:48):
definitely.
I think the only challenge, uh,more related to that, I think is
more, If the developers are notcomfortable with the technical
side of it, they don't know muchabout it, they might have some
concerns initially.
So, I would say that's more likea challenge, just making
everyone feel comfortable withthat as they go along.
But outside of that, I thinkfolks are generally happy about
(18:11):
just having this independenceand ownership.
Ben Lloyd Pearson (18:13):
So you heard it here, do micro frontends,
your developers will be happy.
So what's, what's the ideal endstate for this?
Like it pie in the sky, you've,you've, you've mastered the, the
world of micro front ends.
Um, what is, what is it thatfuture look like to you?
Thayse Onofrio (18:33):
I think that is, there needs to be like, once we
are in a state that is good,that makes sense for everyone,
folks need, can workindependently from each other.
Uh, we need to be careful withhaving like some.
Guardrails in place and alwayslooking into that again because
(18:53):
software is not static, right?
We are always evolving, alwayschanging.
Maybe some part of theapplication previously was not
very important but would not getmuch attention and we decide not
to separate it in a microfrontend at that moment.
But one year from now we need tobuild a lot of functionality
into it.
(19:14):
So now We are seeing like aseparate user flow for that and
now it makes sense to startseparating it.
So I think we always need tokeep an eye on it and making
sure that we are following upwith the evolution of the system
so we can always think if shouldwe break this up?
Should we go back to how wewere?
(19:35):
Maybe, maybe it doesn't makesense anymore, this approach.
So yeah, just thinking aboutsoftware is something that is
always evolving.
I think it's important so wedon't just.
Just think that we've reachedthis peak of everything is good
now, not going to have anyissues because it will not stay
the same, so we need to beconstantly thinking about it and
(19:56):
seeing how we can improve.
Improve.
Ben Lloyd Pearson (19:58):
Yeah, it almost seems like, if I'm
reading between the linescorrectly, it almost seems like
what you're saying is that weneed a world where developers
can easily understand whether ornot something is a thing that
should be broken out into amicroservice or a micro frontend
versus something that is betterto be a part of a more
monolithic structure.
Yeah.
So that, it's, there's, there's,you know, because it does sound
(20:18):
like there's a lot of questionsabout, uh, you know, when to do
that, where to do it.
And, you know, maybe that is,like, the future we need is just
better clarity through talks andsessions like yours, right?
Thayse Onofrio (20:30):
Yeah, I think that just empowering folks with
knowledge and, and they can makethose decisions and bring up
when they see issues and thingsthat, that should be changed, I
think that's really important.
Ben Lloyd Pearson (20:42):
Wonderful.
Um, is there anything that youfeel like we've missed that
you'd like to share about, uh,you know, your session or the
work that you've been doing inthis area?
Thayse Onofrio (20:49):
Yeah, I think one other thing that is really
important about micro frontends,like one of the new challenges
is thinking about the testingpart of it as well.
Uh, because yeah, we can have agreat testing strategy when we
were in this monolith approach,but as we start to break things
up and then we need to composethem, there is a new challenge
of how do we make sure that weare composing things the right
(21:12):
way?
That's the challenge.
Maybe each application workscorrectly by itself, but then
when we integrate it, how do wemake sure everything is working
right?
Uh, so we are just thinking moreabout functional tests, contract
tests, just, uh, looking intothat to see what's the right
approach.
Um, and I think also thinkingabout ownership of doing this
(21:34):
testing because you can have Oneapplication being displayed in
multiple different views, sointeracting with multiple other
micro frontends.
So who is responsible for makingsure that the composition works
as it should in those differentviews, for example.
So yeah, that's definitely a newimportant challenge I think that
we need to think about whengoing through this approach.
(21:56):
And yeah, I would just say ingeneral, just thinking a lot
about the trade offs and, youknow, thinking about the
benefits that we had, but alsoabout those new challenges.
So, it really supports us inmaking those decisions about
when to separate things, how todo it, and should we not do it,
should we do it, so just Havingall that knowledge in place, we
(22:18):
can, I think we can make betterdecisions.
Ben Lloyd Pearson (22:20):
Yeah, so, I mean, if I had to guess, I
imagine micro frontends probablymakes things like unit testing
easier, but then likeintegration and end to end
testing a little bit morecomplicated because now you're,
you're, you have like thismonolith and the microservices
that sort of have very differentways of solving the problem,
right?
Exactly, yeah.
So we really
Thayse Onofrio (22:39):
need to rethink our, our testing approach so we
can make sure that everythingis.
Doing what they should,basically.
Ben Lloyd Pearson (22:47):
Well, wonderful.
I'm super happy that you wereable to join us today for this
conversation.
Are there any other last wordsthat you want to leave our
audience with?
Thayse Onofrio (22:57):
Oh yeah, just getting to know more about it.
You know, just go after thisknowledge about micro frontends,
but also anything that makessense to think about how we can
improve collaboration betweenteams when working together.
Just trying these new things, Ithink it makes a lot of sense to
(23:17):
experiment, see what works, seewhat doesn't work, but having a
lot of flexibility to tryingthings out and see what makes
more sense and can bring morevalue to our teams.
And yeah, if you have thoseissues, I think it makes a lot
of sense to try Microfront EndsOut.
It's not bulletproof.
There are new challenges withit, but that it can really bring
(23:37):
a lot of benefits.
So I would encourage folks totry it out.
Ben Lloyd Pearson (23:43):
So if our audience wants to learn any more
about you, your work, thecompany you work for, where's
the best place for them tofollow?
Thayse Onofrio (23:50):
Yeah, uh, I actually have a blog, it's
taizionoffshoot.
com.
Uh, so I write some stuff there.
Uh, I will publish some talksthere as well.
So.
Feel free to check it out.
Also, social networks the samehandle.
Uh, yeah, I think that's it.
Ben Lloyd Pearson (24:07):
Wonderful.
Well, thank you Thae for comingto joining our podcast today.
It's been a real pleasure.
And yeah, thanks.
Thayse Onofrio (24:13):
Thank you for having me.
If the developers are not comfortable
(00:01):
with the technical side of it,they don't know much about it,
they might have some concernsinitially.
So, I would say that's more likea challenge, just making
everyone feel comfortable withthat as they go along.
But outside of that, I thinkfolks are generally happy about
just having this independenceand ownership.
Ben Lloyd Pearson (00:20):
So you heard it here, do micro frontends,
your developers will be happy.
How can you drive developerproductivity, lower costs and
deliver better products?
On June 20th and 27th LinearB ishosting a workshop that explores
the software engineeringintelligence category.
We'll showcase how data-driveninsights and innovative workflow
automations can optimize yoursoftware delivery practices.
(00:44):
At the end of the workshop,you'll leave with a
complimentary Gartner marketguide to software engineering,
intelligence, and otherresources to help you get
started.
Head to the show notes orLinearB dot IO slash events to
sign up today.
Hey everyone.
Welcome back to Dev Interrupted.
I'm Ben Lloyd Pearson.
I'm the Director of developer rerelations at Linear B.
I'm pleased to be joined by ThaeFerro, uh, the lead software
(01:07):
engineer at ThoughtWorks.
Thae, thanks for being here.
Thayse Onofrio (01:10):
Thank you.
Thank you for having me.
Very happy to be here.
Ben Lloyd Pearson (01:13):
Yeah, wonderful.
I, we, we were talking, we had along trip from Brazil, so glad
you made it here So.
So, we're going to talk a littlebit about the session that you
have here at this event.
But, you know, I'm sure we'lltouch on other subjects too.
But, you know, the main thing isthat, you know, as apps expand,
that are needed to manage thevarious functionalities.
(01:33):
And without the rightinfrastructure, you know, this
growth can lead to a host ofissues from communication
challenges and code conflicts tobusy pipelines, tangled release
interdependencies.
It can be a pretty complexpicture, and your talk is all
about the solution you've comeup with, which is micro front
ends.
And this architectural approachhas allowed individual
(01:56):
application components to beoperated and deployed
independently to sort of get outof that like monolithic maze
that a lot of companies arefacing.
So I want to talk about, youknow, what the future of
frontend development looks likewithin this context.
But before we get into that,let's just get into the basics.
So what is a micro frontend?
Thayse Onofrio (02:20):
Very much related to microservices, what
is more popular.
Uh, but the same way microfrontends, we have like smaller
frontend applications, but wecan develop and deploy them
independently from each other.
Each having their ownresponsibilities, but then they
all look the same for the user.
So, as a user looking at thisapplication like if it's a web
(02:41):
application, it doesn't reallymatter to me how they are, how
it's done, how everything wascreated.
Uh, but When we look into howit's being done, developed,
deployed, everything isseparate.
And we just compose themtogether.
So for a user it shouldn'treally matter, but for the teams
working on it, it makes a lot ofdifference.
If it's not like a wholemonolith and we can work on our
(03:04):
own thing without having so manyconflicts and blocking each
other all the time.
Ben Lloyd Pearson (03:08):
Awesome, awesome.
So, so let's, let's talk aboutsome of the unique challenges
that you've encountered whiledoing this, uh, cause, you know,
uh, you know, I like thecomparison to microservices,
that, that, like, that concepthas been around for a little
while, so people are, are prettyfamiliar with it.
What are the unique challengesthat you've faced while you've
been implementing this microfrontend?
Practice, specifically relatedto like the monolithic
(03:30):
architecture.
Thayse Onofrio (03:31):
Yeah, I think with monolith architecture,
especially when the teams startgrowing too much, we can get a
lot of, uh, conflicts.
And if you have different teamsworking on the same code base,
it But maybe even differentproducts.
It can be very confusing foreveryone working on it.
Uh, that needs to be a lot ofcommunication within everyone.
(03:52):
And that doesn't happen if youhave separate teams.
Even in the same team, sometimesthere is not enough
communication happening.
Uh, so we start to facing a lotof issues if we are using the
same pipelines, like thepipelines are always busy, there
is no enough resource to handleit.
So, it starts to get reallychallenging and I think one of
the most pain points isdeployment because you have to,
(04:15):
one team depends on the otherteam to do a deployment, so you
don't have that, um, flexibilityabout just being able to deploy
whatever you want, uh, it canreally slow the team down,
having to depend one team on theother.
So I think that's where, and alot of times, going towards this
micro front end approach reallyhelps.
Thanks.
And then we can, and there are alot of different techniques we
(04:37):
can use to get to this approach.
Uh, but yeah, I think definitelylooking into that and seeing
what makes more sense for yourteam.
And depending on the tech stackthat the team is comfortable
with as well, uh, you can findan approach that you can start
like slowly going towards thisand separating things out as
much as possible.
That brings a lot of benefits, Ibelieve, to the teams.
Ben Lloyd Pearson (04:59):
Let's dig a little bit into the technical
side of this.
Have you been relying mostly onlike out of the box solutions or
existing, libraries that are outthere?
Or did you have to build a lotof this yourself, like from
scratch?
Thayse Onofrio (05:10):
Yeah, I think now there is a lot of options.
Uh, I think previously mostlydoing that on the server side.
Uh, but now we have, and I willtalk on my talk as well a lot
about using module federation,uh, which uses Webpack to do it.
Uh, so it's way simpler becausenow a lot of front end teams are
already using Webpack,everything, like you already
(05:30):
have everything configured, youjust need to add a new plugin
to, to use module federation.
So that really helps.
But yeah, I think there are manymore solutions now, it's
becoming more popular.
It's easier to get started, Iwould say, for most teams that
are already using a lot of thosetechnologies.
Ben Lloyd Pearson (05:49):
So, you know, you know, in, in front line,
front end libraries inparticular, you know, I feel
like that's a, that's an area oftechnology that has just, I
mean, it's, it's become a memejust how many different
libraries and services are outthere.
I see all these posts on, onsocial media about how there's
too many of them and how, uh,you know, when everything is
like working together and sortof like the golden package, it
(06:11):
can be great, but the momentyou, you try to like, Breakout
of the, like the, the cookiecutter formats, um, particularly
with JavaScript.
Um, that, you know, it can getpretty difficult, you know,
cause there's, I mean, there'shundreds, maybe even thousands
of libraries that you can choosefrom out there.
So I'm, I'm wondering, you know,how did this complexity affect
your ability?
Like, did, did you have tochange how you approached the
(06:33):
challenge?
Were, were there specific groupsof libraries that you found
beneficial, you know, just ingeneral, like, what kind of
challenges does that, thatcomplexity of just how many
options are present?
Thayse Onofrio (06:45):
That's a great question.
I think a lot of people actuallysay that one of the benefits of
using micro frontends is thateach, uh, micro frontend that
you have can have their own texttag.
So you can choose to do thisfrontend in one library, this
other using another library, andthen you just kind of stitch
everything together.
That's possible, that works, butI wouldn't recommend it.
(07:09):
So, if you are looking at thesame view and you are loading,
like, just as a user going to aweb page, I would have to
download a bunch of libraries,dependencies that not really
needed, and that can reallybecome complex to manage and
really affect the performance.
So, it's that kind of thing thatit's possible, but that doesn't
(07:29):
mean you should do it.
And, yeah, and even if, ifyou're using the same, uh,
libraries, you have to becareful about versioning.
If you have, like, differentfrontends in different versions
of, of those libraries, how willthey interact once you are
composing them together?
So that's, that's a big concern,I would say, with using micro
frontends as well.
Just being careful with using somany different libraries.
(07:53):
There needs to be, like thesystem needs to work together
also.
You need to have a lot ofcoordination between the micro
front ends in a lot of ways.
And I think dependencies is oneof them.
Ben Lloyd Pearson (08:03):
Yeah.
So do you, do you give teamslike a lot of leeway to sort of
build that or define that paththemselves?
Or do you rely more on sort oflike, do you give developer
teams like, like solutions or,or guidance on this?
Or do you let them kind ofchoose their own path more?
Thayse Onofrio (08:20):
Yeah, I think there needs to be a lot of,
coordination in that in a sense,and, I think it's a bit
challenging because you do wantthe teams to have their own
freedom of choosing what path tofollow, but there needs to be
some kind of, uh, governancearound it.
So I think it really depends oneach context and each team, but
(08:41):
usually having someone that canat least set the, uh,
Guidelines, set some, uh,guardrails around it really
helps.
So you avoid like having oneteam going completely different
way than the other and thencreating those complex
challenges.
Uh, so yeah, just having a forumfor the teams to talk about it
as well really helps, but Iwould say just setting
(09:03):
guidelines and, uh, I think alot of teams also use these,
templates to get started as, asa micro frontend.
So you have like some librariesthere.
You have some.
Guidelines that are automatedalready to get started.
So at least teams get started inthe same direction, you know.
Ben Lloyd Pearson (09:21):
So, one other thing that, uh, you mentioned,
uh, or you mentioned in your,your talk is, uh, uh, some of
the complexities around buildpipelines.
So, so, you know, a monolith canha is typically going to have
very different buildrequirements from a, you know,
front end microservice.
So, how has that played intothis, uh, into this equation
(09:43):
and, you know, what sort of,what sort of things have you had
to do to, to overcome challengeswith that?
Thayse Onofrio (09:48):
When we are in a monolith approach, the pipeline,
uh, when we need to handleeverything related to that, so
we can become challenging.
And then when we start to breakdown each front end monolith,
micro front end actually, willhave its own, uh, build pipeline
so you can build and deploy codeindependently from each other.
But I think it really helps thatyou can add the sort of
(10:11):
validations that you need basedon that specific framework.
Um, piece of, uh, microfrontend, which doesn't
necessarily is the same as theother.
So you can really adapt that andmake sure that you are having
the right validations, you arebuilding code the right way for
that specific piece of code andgetting that into production.
(10:31):
Uh, so yeah, I think it justgives a lot more flexibility.
So each team can do what'sneeded for their own challenges.
Ben Lloyd Pearson (10:39):
Gotcha.
And it seems to be like that's abig theme with rolling this out.
How many developers do you haveat your organization?
Thayse Onofrio (10:48):
It really depends on the teams that I'm
working with as a consultancy.
It changes a lot, but I thinkthe last time I was working with
this, in my specific team, Ithink we were around eight
people.
Ben Lloyd Pearson (11:00):
Okay, okay, gotcha, yeah.
Because I just know when thingsget big and complicated in the
developers world, like, uh, youknow, it is great to offer like
a lot of those, um, liketemplates effectively that sort
of set them in the rightdirection.
But there's always just so muchnuance to the technologies, to
the processes those teams use.
(11:21):
So I'm wondering what, what'syour What does it take to
migrate, you know, what, fromthis like monolithic design to
one where, uh, you're doing moremicro frontend, maybe even some
microservices, you know what,what's step one?
What's, what do you do afterthat?
Like, is there, is there apredictable progression or, um,
is it more nuanced than that?
Thayse Onofrio (11:41):
Yeah.
I would say that the initialthing, and one of the most
challenges part is understandinghow you are going to do that in
terms of.
Which parts of the applicationcan be separate modules, how
you're going to break thingsapart.
So thinking about boundedcontext and how do you get to
that approach of knowing thisshould be a separate module,
(12:03):
this other thing should be itsown module.
So I think that's the most scarypart in the beginning, trying to
do the right thing, because atthe same time that you want to
get all the benefits ofSeparating things out, you don't
want to get too granular,because otherwise then you are
just adding new challenges andnot really getting the benefits
out of it.
So there needs to be like abalance of where it makes sense
(12:28):
to do it or not, much likemicroservices.
Um, and yeah, if we are able toalign like the microservices
approach with the microfrontends approach, I think we
get a lot of value out of itbecause then we have this one
deployable unit of code.
Uh, and getting all the benefitsfrom, from all of that.
Uh, but I would say, yeah, thefirst thing is understanding
(12:50):
exactly how to do it in terms ofwhich will be the, the physical
and ownership boundaries ofthose micro frontends.
And then you can start lookinginto thinking about the trade
offs, like what, what will bethe benefits added, what will be
the new challenges that we'llget.
Because there is always tradeoffs, always we need to think
about the, the new challenges aswell.
(13:11):
And then I think we can move onto like, choosing the approach,
how we are going to do that, andreally take into consideration
what's the team's knowledge ofthe tech stack as well, so you
can choose an approach thatmakes sense for the team, that
it's not everything new forthem, that they need to learn
everything from the beginning,you know?
So then, after you do that, Ithink you can start actually
(13:32):
doing the migration, andthinking about small steps as
much as possible.
What's the minimal thing thatyou can do that you can start
already to get some value out ofit before you move on to
increasing that.
So doing that as slowly aspossible in a way that we are
not impacting user experience,right?
(13:53):
Because we can't just stopworking in what is live in
production and stop maintainingit, stop adding functionality to
it, just start working onsomething new from scratch.
So we need to find a way to dothat, uh, a little bit more
slowly and.
Starting to get value out ofthese, these changes.
Ben Lloyd Pearson (14:11):
Nice.
So use use a phrase there thatI've never heard before that I
want to dig into a little morebounded context.
that is a, I feel like I shouldknow what that means.
Maybe can you explain a littlemore like what exactly you're
describing there?
Thayse Onofrio (14:25):
Sure.
Yeah.
Uh, so bounded context is aconcept from domain driven
design, DDD.
Uh, so here we are talking aboutthis, uh, finding these
boundaries about like physicaland ownership boundaries.
And it really means that eachbounded context should be an
independent service, and in thiscase talking about micro
frontends, that should beevolved independently from one
(14:47):
another, so developed andmaintained independently, but
while they should work togetherto create this unified system.
So really what we want toachieve here with micro
frontends, but it's a conceptthat doesn't really need to be
attached to a specific approachlike microservices or micro
frontends.
But I think both of theseapproaches, uh, feed from
(15:10):
bounded context and, and DDD inthat sense.
Ben Lloyd Pearson (15:13):
So, it, it, because it, it kind of sounds
like this is, like, kind of acritical aspect of understanding
where to, like, where to begineffectively.
It's like, where, where can youpick a part of your UI that you
can just pull out and make thatyour first, like, microservice.
So, for an organization that islike, wow, this sounds amazing,
I want to do this.
Like, like, how do they findthat first?
Thayse Onofrio (15:38):
That's definitely, I think, very
challenging, and I think itreally helps to think about the
user flow, like how the userinteracts with your page, so you
can start to think about, whatis the flow that the user is
doing here.
And you kind of start seeingthat the user is going to focus
on one specific part instead ofthe other.
(15:59):
So you start to see how things,uh, are separate from a user
point of view.
And then you can think about howthat would make sense from the
development, team point of viewas well.
Starting to separate that out.
Um, but yeah, I think using, uh,A lot of those, DDD tools as
well might help.
Uh, I'm not an expert in it, soI'm not going to dive deep into
(16:23):
that, but just studying a littlebit about it, I think it would
really help for someone whowants to start going towards
this and separating things out,trying to think about what
approach you use for that.
Ben Lloyd Pearson (16:35):
Wonderful, wonderful.
So have there, have there beenany sort of, like, cultural
changes that you've had to do,like, in terms of, like, how
people think about how theybuild code or, um, the way they
approach problem solving, uh, asa result of adopting, uh, like a
micro front end framework?
Uh, you know, so beyond, like,the technical challenges and
(16:57):
even the process, like, isthere, is there cultural
challenges that you have toovercome as well from an
engineering perspective?
Thayse Onofrio (17:05):
Great question.
Yeah, I think mostly teams aremore, are usually happy, you
know, about being able to havemore ownership about their own
things.
Not having to rely so much onother teams and other folks.
Uh, and just, yeah, having moreindependence in that way.
So I don't think there is somuch cultural challenge.
I think It's more like
Ben Lloyd Pearson (17:26):
opportunity, right?
It, it's like you're, it's a wayto empower developers while also
giving them a framework to be alittle bit safer.
Mm-Hmm.
you know, uh, have a little lessrisk.
I imagine.
So, yeah, I mean that's, that'sactually a great point I think
is that this is a great way tomake, to encourage your
developers to be a part of apositive cultural change, you
(17:47):
know?
Yes,
Thayse Onofrio (17:48):
definitely.
I think the only challenge, uh,more related to that, I think is
more, If the developers are notcomfortable with the technical
side of it, they don't know muchabout it, they might have some
concerns initially.
So, I would say that's more likea challenge, just making
everyone feel comfortable withthat as they go along.
But outside of that, I thinkfolks are generally happy about
(18:11):
just having this independenceand ownership.
Ben Lloyd Pearson (18:13):
So you heard it here, do micro frontends,
your developers will be happy.
So what's, what's the ideal endstate for this?
Like it pie in the sky, you've,you've, you've mastered the, the
world of micro front ends.
Um, what is, what is it thatfuture look like to you?
Thayse Onofrio (18:33):
I think that is, there needs to be like, once we
are in a state that is good,that makes sense for everyone,
folks need, can workindependently from each other.
Uh, we need to be careful withhaving like some.
Guardrails in place and alwayslooking into that again because
(18:53):
software is not static, right?
We are always evolving, alwayschanging.
Maybe some part of theapplication previously was not
very important but would not getmuch attention and we decide not
to separate it in a microfrontend at that moment.
But one year from now we need tobuild a lot of functionality
into it.
(19:14):
So now We are seeing like aseparate user flow for that and
now it makes sense to startseparating it.
So I think we always need tokeep an eye on it and making
sure that we are following upwith the evolution of the system
so we can always think if shouldwe break this up?
Should we go back to how wewere?
(19:35):
Maybe, maybe it doesn't makesense anymore, this approach.
So yeah, just thinking aboutsoftware is something that is
always evolving.
I think it's important so wedon't just.
Just think that we've reachedthis peak of everything is good
now, not going to have anyissues because it will not stay
the same, so we need to beconstantly thinking about it and
(19:56):
seeing how we can improve.
Improve.
Ben Lloyd Pearson (19:58):
Yeah, it almost seems like, if I'm
reading between the linescorrectly, it almost seems like
what you're saying is that weneed a world where developers
can easily understand whether ornot something is a thing that
should be broken out into amicroservice or a micro frontend
versus something that is betterto be a part of a more
monolithic structure.
Yeah.
So that, it's, there's, there's,you know, because it does sound
(20:18):
like there's a lot of questionsabout, uh, you know, when to do
that, where to do it.
And, you know, maybe that is,like, the future we need is just
better clarity through talks andsessions like yours, right?
Thayse Onofrio (20:30):
Yeah, I think that just empowering folks with
knowledge and, and they can makethose decisions and bring up
when they see issues and thingsthat, that should be changed, I
think that's really important.
Ben Lloyd Pearson (20:42):
Wonderful.
Um, is there anything that youfeel like we've missed that
you'd like to share about, uh,you know, your session or the
work that you've been doing inthis area?
Thayse Onofrio (20:49):
Yeah, I think one other thing that is really
important about micro frontends,like one of the new challenges
is thinking about the testingpart of it as well.
Uh, because yeah, we can have agreat testing strategy when we
were in this monolith approach,but as we start to break things
up and then we need to composethem, there is a new challenge
of how do we make sure that weare composing things the right
(21:12):
way?
That's the challenge.
Maybe each application workscorrectly by itself, but then
when we integrate it, how do wemake sure everything is working
right?
Uh, so we are just thinking moreabout functional tests, contract
tests, just, uh, looking intothat to see what's the right
approach.
Um, and I think also thinkingabout ownership of doing this
(21:34):
testing because you can have Oneapplication being displayed in
multiple different views, sointeracting with multiple other
micro frontends.
So who is responsible for makingsure that the composition works
as it should in those differentviews, for example.
So yeah, that's definitely a newimportant challenge I think that
we need to think about whengoing through this approach.
(21:56):
And yeah, I would just say ingeneral, just thinking a lot
about the trade offs and, youknow, thinking about the
benefits that we had, but alsoabout those new challenges.
So, it really supports us inmaking those decisions about
when to separate things, how todo it, and should we not do it,
should we do it, so just Havingall that knowledge in place, we
(22:18):
can, I think we can make betterdecisions.
Ben Lloyd Pearson (22:20):
Yeah, so, I mean, if I had to guess, I
imagine micro frontends probablymakes things like unit testing
easier, but then likeintegration and end to end
testing a little bit morecomplicated because now you're,
you're, you have like thismonolith and the microservices
that sort of have very differentways of solving the problem,
right?
Exactly, yeah.
So we really
Thayse Onofrio (22:39):
need to rethink our, our testing approach so we
can make sure that everythingis.
Doing what they should,basically.
Ben Lloyd Pearson (22:47):
Well, wonderful.
I'm super happy that you wereable to join us today for this
conversation.
Are there any other last wordsthat you want to leave our
audience with?
Thayse Onofrio (22:57):
Oh yeah, just getting to know more about it.
You know, just go after thisknowledge about micro frontends,
but also anything that makessense to think about how we can
improve collaboration betweenteams when working together.
Just trying these new things, Ithink it makes a lot of sense to
(23:17):
experiment, see what works, seewhat doesn't work, but having a
lot of flexibility to tryingthings out and see what makes
more sense and can bring morevalue to our teams.
And yeah, if you have thoseissues, I think it makes a lot
of sense to try Microfront EndsOut.
It's not bulletproof.
There are new challenges withit, but that it can really bring
(23:37):
a lot of benefits.
So I would encourage folks totry it out.
Ben Lloyd Pearson (23:43):
So if our audience wants to learn any more
about you, your work, thecompany you work for, where's
the best place for them tofollow?
Thayse Onofrio (23:50):
Yeah, uh, I actually have a blog, it's
taizionoffshoot.
com.
Uh, so I write some stuff there.
Uh, I will publish some talksthere as well.
So.
Feel free to check it out.
Also, social networks the samehandle.
Uh, yeah, I think that's it.
Ben Lloyd Pearson (24:07):
Wonderful.
Well, thank you Thae for comingto joining our podcast today.
It's been a real pleasure.
And yeah, thanks.
Thayse Onofrio (24:13):
Thank you for having me.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.