>> Hello, everyone.
How are you today?
I hope you're doing great because today I have
a great subject to talk about with you.
Today we're going to be talking about
Micro Frontends with Webpack's Module Federation Plugin.
I know that you must have heard somehow about Micro Frontends.
If you haven't please raise your hands.
Good. Well, today we're
going to try to clear up some of those things.
If you don't understand or never heard about it as well as
Module Federation what it is and where can we use it?
Who am I?
My name is Daniel Frey.
I'm originally from Israel.
I'm a senior frontend developer at IO,
which is a consultancy company in the Netherlands,
which is where I'm also located right now.
I also love to create content.
At danielfrey.me I have also a podcast where I share
my experience along with other people about various projects.
I really recommend you go and check that one out.
I also love meeting and collaborating with people and you
can also follow me on my Twitter account,
which is DanielFrey101 and
I re-post and talk about bunch of different things.
This is related to technology of course,
and frontend development,
and I'm also really passionate about accessibility UX UI.
Before we dive in into
this brand or maybe new subject to yourself,
we need to understand the reasoning behind it.
These days we have
at least very other week we have
a new framework coming in JavaScript.
You can either be
naive or you can either understand where it's coming from.
Let's start with that. Let's identify some goals.
First of all, whenever we create an application or a theme,
we want to have those points.
We want to have fast and predictable delivery.
We want to have a maintainable code bases,
the ability to scale our theme and technology while keeping
also up to date with
the recent technologies and picking up the right tool for the job.
Now let's have a look at the traditional way.
Currently, we have a backend with
micro services and a frontend and monolith frontend,
where you have this huge react application
which you can also manage with
maybe monolith and however you choose to manage it currently,
but you communicate with the backend that
is built on micro services.
Now obviously, the micro services
has been there for a while and you might be thinking,
micro services and micro frontends.
I start to see some connection.
Well, hold up your guts there and let's continue with
the next slide and the struggles of monoliths and the frontend.
Obviously, whenever we choose a technology for our application,
we have something called technology lock currently.
If we chose Angular JS back in 2010,
there's most likely going to be the acting technology
of the choice of the entire lifetime of this application.
Now, what if there is
an objectively better tool for a certain job?
Or what if the technology advances?
Another problem or issue.
A struggle is single deployment,
communication overhead,
so releases need to be coordinate carefully.
The application is most likely to break due to other teams work
and which basically resulting in affecting our delivery time.
Another thing is that maintainability.
Maintaining a big application is already
difficult enough than it is already now.
Basically, maintaining a smaller application is just easier.
If we could or maybe we can.
More moving parts and interview dependencies,
resulting in difficulties to introduce changes obviously.
Fourth problem is process overhead.
The process of introducing changes becomes tiring.
Minor decisions become major as they affect the other teams,
and teams need to communicate
closely before making certain changes,
which basically costs time.
Now, you might be asking,
Daniel, what is the solution?
Well, let me show you something.
Here, there is basically SPA application really simple.
It shows you my latest episodes on my podcast.
You have a card, you have a header and a footer.
On the card you can either play the episode or you can like it.
When you like it,
you're going to see that you have a mini cut
here where it shows you what you liked.
Also, when you click on the episode,
you can basically see
the episodes details and again, you can unlike or like it.
Whenever you click here on this card
that list you will see a checkout button. When
you click on the checkout board and you're going to see
basically the list of episodes that you liked.
What you can do, we can check out and
that's just going to clear the cards.
Just very simple application.
Now, what if I told you that those were four separate websites?
Those websites shared their routing
and they even shared the lightning cards
and I could deploy
every single one of those websites independently of the others,
and changes will reflect immediately.
I know, right? The game came changes here.
Where you have a header and a footer and
basically they can be in their own repository.
We have a mini card,
which is also a part of the liking card repository.
We have the media player which has its own repository as well,
our project and episode content
and then even the like button is part of,
basically of this like cards repo but it
shows in the card and they're just using each other.
Then it's resulting in something like
this where we can split our teams,
if you will in chapters or
episodes or however you would want to call it,
where things are working like that.
Where you have Team D prefers to use Vue.js,
for example, they could.
Now, how and why would you?
That's another thing
but you could basically do that. You can split.
We have the header, we have the footer,
and let's say Team A is in charge on that.
Team B is in charge on the episodes details.
The checkout page, that is Team C,
basically the player part
is Team D. That is build in Vue.js, if you will.
Of course, now that we understand what micro frontends,
and you might be thinking, hey, Daniel,
how do I apply it and probably use NPM packages?
Well, versioning is stuff.
Let's say we have those four different projects.
We're deploying them through using NPM.
Let's say in the home page,
I updated the header and the header
is being used also in the content page obviously.
Then what's going to happen is that if I'm using an NPM package,
I will have to redeploy my home page,
also deploy my content
or let's say also the header
is being used not only in the content but
also being used in the light card on player. Doesn't matter.
They have dependency between each other and you have to update
them or redeploy them to show the latest changes.
Well, let me show you something that is
called Webpack's Module Federation Plugin.
Do you want to update the header? No problem.
Here in the video, you can see a really simple example
where I have the header as a title,
''Helllooooo'' and then I change it to
Welcome to danielfrey.me Talks,
and I actually I'm in the content project,
but I change it in the header project
and I just save the changes and it's just basically have
a runtime deployment or
runtime changes that are immediately represented on my page.
How it works is basically
just Webpack is hooking you something with
the Module Federation Plugin
and you have this basically different properties
there where you consume them.
It looks something like that.
You have basically the,
the webpack.config and each one of
your application or projects where you have the micro of these,
and you have something called name,
which is basically the name of your application,
you have something that is called exposes here and remotes.
The remote is what you're consuming to
your application in this application and exposes,
if you will, components that you're
exposing outside for the world to use.
That is how this magic is happening.
If you think about how does importing work,
just look at it.
It does look like really simple as if you're using an NPM package
but again, you're not.
This is just Webpack's Module Federation doing its work
for you and it's actually looking pretty slick.
Well, let's review.
Before we had this technology log,
you had this maintenance,
you had this communication overload
and all the teams had to basically really be close,
tightly coordinate with each other.
Right now, on the other side,
you have basically different teams
are responsible on a very small part of the application.
Imagine your team is only responsible on header and footer.
You don't have to think any more about the whole application.
Isn't it easier than to maintain that small application?
Do you want to change technology because
your current technology is not up to date?
You could if you wanted to.
Do you want to go to production faster because you have
basically an e-commerce website and
you want to change the header to be on Black Friday?
You just don't have time now to
redeploy all your applications
to show that in an e-commerce website,
which you have tons of pages.
Then you just upload the header and live reload it and
it just gives you that power that you have.
I want to just stress here that my,
Webpack module federation, again,
is just a tool to apply basically, micro frontends.
Micro Frontends is the thinking, the architecture
but the tool that we use here basically
gives us this power of the live reloading
and we don't have to redeploy our applications.
There are other tools of doing that.
You can also be using iframes.
I'm just giving examples of things that I've seen
but again, I want you to understand this is also not perfect.
You could be still having certain issues in
your current team about communication overhead,
but now it's just being really reduced to that team level.
Now, who uses micro frontends?
You might ask yourself.
These are the companies,
basically the big names that use that.
Now, it means that you need to use it right.
We're not at that you sign the beginning with the bright eyes.
You know better now.
I really want you to think,
does this make sense in my company?
Also, I want to mention that
these companies are using Micro Fes,
but it doesn't mean that they're using
module federation. There you go.
You need to understand that these are a bit different.
Now, you may have some concerns.
Of course, when I build my project in Micro Fes,
I was thinking,
aren't I importing packages more than once.
With this I have now,
this home page and I have a lot of it of course Micro Fes.
Aren't I importing react like a lot of times?
Well, you're not.
There's something called the singleton mode.
Basically in each of your projects you're going to have
a Webpackconfig.js where you
have a section called shared where
you have react as a singleton through.
Where you're going to import it only once.
You're going to have react dom there.
Obviously in this project we use only [inaudible] on the react.
In your case it might look a bit different, but again,
it's there and you can avoid
importing over and over again those packages.
One thing cleared out.
Another thing is that what about TypeScript support?
This case might happen where I have
basically imported this package.
Again, this is not an NPM package.
Right now you can really see it that it's not.
My ID doesn't recognize it.
It doesn't understand what the hell is happening.
Basically, I found online few ways to right
now fix it and I want to mention I'm not
a typescript pro and I think also the solution
is you can say not going to be the best.
But again, there is a solution and
actually there are talks right now with Microsoft
about fixing those issues to
improve it as the support for module federation.
But what you can do is basically declare modules.
Here I created the content.d.ts where I declared
the different modules that I'm using and it
basically solves then the issue that we just saw,
right now this issue.
Another thing that you can do is the link types.
Basically, whenever you are using
a component which has a certain type definition on it,
you need to basically look at this prop has to be a string, right?
Or this prop has to be a number.
Now, you can do that basically with linking them together.
Well, what about versioning?
No versioning in runtime reload
but what if the header theme basically, if you will,
adds in mandatory prop and I'm not aware of it?
Well, there is something you can use,
error boundaries in React.
By the way, this is not going to other frameworks.
In other frameworks, you will have to find a solution for that
but basically, it must be a class component.
That can be for those people who
basically been using hooks
now and they're only using functional components.
This is actually the only case that I've seen that
actually is a good case to use class components.
The way it works, you can just use this as a regular component.
We have a new compliance called error boundary and I
have basically wrapped my header component now or if you will,
the header section in my project with the error boundary.
Now if that fails to load because of some reason or
something went wrong like the header team wanted a prop.
They wanted to have now a title
and I didn't give it a title because
I didn't need to give it previously.
Of course we have loaded without.
They updated it, now it'll break.
There is something, of course and now it's handling it.
Then it will show something is wrong.
Now this is much better than the whole application is failing.
Also, you can still use the other parts.
There is no problem and the worries there.
Now, I hope that some of
your concerns have been addressed now
and here are some of the resources that I've used.
I want you to mention a couple of things.
First of all, if you want
all the code and everything that you need is in my GitHub profile.
Also, the module federation,
I would recommend to read a bit more about it.
You can do it there.
I also want to mention and shout out Ariel,
really helped me with providing context and reviewing
this talk. Thank you, Ariel.
I also want to recommend to use this article.
I don't understand micro-frontend from Luca,
which talks a lot about micro frontends
and has some information around it.
If you have any questions,
hit me up, let me know.
Would love to answer them
and thank you so much for listening and attending.
Also, I'm really always
welcoming and reachable on LinkedIn or Twitter,
and if you want to meet up in
person or online talk about anything, just let me know.
I also love to host like interesting individuals on my podcast.
If you might want to join as a guest, also let me know.
Feel free. Thank you so much.
Have a wonderful evening day wherever and what time,
whatever you're listening to this. Goodbye.