States, Components and Libs management in Micro-Frontends

Good afternoon everyone.

Thank you for joining my sections about micro frontends date.

But before I dive into the concept and implementation about a micro frontends, I would like you to you to gimme a bit a begin with the why.

Why people use micro frontends.

As a member back to about year ago, my manager, he come and asked me questions.

David, I would like you to start your project building a web, document uploads website.

What would you consider for this project?

What do I need to consider to start new project for building a document upload website?

First, it was three things coming on my mind.

Number one is the goal.

The goal of the project is to build a UI, build a UI website for clients, upload files.

And second thing got my, in my mind is I lead to have a team of peoples, I lead a team of people, testers, front end developers, backend developers as well.

And also in doing a project, I need to decide a technical stack.

I can decide to use React, right?

If this sounds quite straightforward, when it comes to considers, when you start to do a project, then James, my manager, asked me again.

Now what if I change it a bit?

I would like to build a product.

Instead of building a project of file upload, I now, I want to build a product for file management systems.

Oh, things become complicated, right?

From a project to a product.

What you have to consider become a lot more complicated.

At least three things will be become getting more complicated.

First, when we're doing a project, usually that we are single goal, file uploads.

The goal is to upload files, but to build a product for people to management files.

There will be involved multiple business domains.

Yes, you need a page for clients to upload files, but you also need to offer functionalities.

Like file search.

Like files need to be shared.

People need to be logged in.

And people need to pay for your product.

You need a subscription page, things become more complicated.

Domain getting bigger and bigger.

A single project goal now is replaced by a product lead for multi multiple functionalities.

What else?

Teams is also changed.

When we're doing a project, usually I got a small team of people, maybe five, maybe 10.

But when we're doing a product, usually you have multiple teams working togethers.

You have the teams working for a file search functionality, you could, you have another teams focusing on subscriptions, getting people's payment coming through, and each of these teams will have different focus.

They have their own priorities.

They want to release their features independently.

Also when we're doing a project that's with team, that's internal teams communications.

But when we're doing a product that involves lots of course teams collaborations to make the products ready to use.

And as well as because the multiple teams they want to deliver with their feature independently, one team's work should not be a blocker of another teams.

Certainly the question changed a little bit from a project to a product, but the challenge changed a lot more.

Then James, my manager, asked me the last questions, so what's the solution for this?

What will be the solution for all these challenges when we are doing a product?

That will be today's topic, micro frontends.

Then how are we gonna implement micro frontends?

But before I dive into the implementations about micro frontends, I want us together to have a review of the definitions about micro frontends first.

So micro frontends is an architecture for building on modern web applications with multiple teams that can ship feature independently.

What I say is micro frontend is an architecture, so that's not a single language.

Micro frontends decide to build modern web applications.

That's something helped you to build product.

Micro frontend enable enables teams to work in parallels.

It enables teams to deliver features independently.

Yeah, that's perfect.

That solved the challenges, but what else?

That's not the end, but we started getting a bit more interesting.

Let me show you a little bit more about other benefits while using  micro frontends as well.

As I mentioned, when in the products environment you got multiple teams, each teams can choose their own languages.

Can choose their own framework as well as different versions.

In the product teams you have the teams they focus in, they want to use JavaScript, while the other teams, they want to use TypeScript.

You have a Angular team.

You have a React Teams, you have a real JS teams.

We also have some legacy page.

They're still running with React 18, React 14, while the latest page you wanna build up with, React 18.

Micro frontends created a great connection between all of them.

So that means using micro frontends, you can mix multiple technologies, multiple languages, multiple framework, and even different versions together to build your product.

Secondly, with micro frontends, you can, you could feel that innovations and upgrades is faster than before.

Because  micro frontends allow you to delivery features and upgrades independently in terms of testings, since those components that can shift independently, so the testing scope will be significantly reduced in the area released, the tester will be mainly focused on the dependency or the single component that can release, testers will become happier than before.

What about developers?

If you wanna try some new ideas, you can try on a single components instead of that single choice goes to the whole applications.

The third one, benefits: micro frontends promotes share components and share dependencies.

With share components you can see the benefit will be, you can have the whole application would be have the same look and feel.

With shared dependence, instead of the clients that have to download multiple instance or lodoash dash libraries, they only have to download it once.

So screenshot on the client's browsers will be much quicker than before.

Also, micro frontends allows errors isolations, and fault tolerance.

A single module failure or single components fail, it won't crash the whole applications.

Taking the My project, the file upload dashboard as examples.

The payment system or the payment modules failure, it won't crash the whole applications.

You can still upload files, you can still search files, but no payments you need pay.

Last, but not least microfrontends tells you can reduce cost team config because it enables multiple teams to deliver with their features independently.

It reduce the overlaps between each team's focus.

It reduce the bottle necks, it allows much faster time to the market so, the client will be a lot happier.

I've gone through micro frontends, can solve the challenges while I'm starting my new product, and also bring up with that five different benefits.

I think it's a great time to talk about implementations, how we're gonna do micro frontends as show in the definition.

micro frontends is an architecture.

It's not a single language.

Micro frontends can be implement in multiple different ways using different languages.

For the team that going with NextJS or there being a product which is SEO friendly, you can implement micro frontends in the server side.

So that's server side integrations.

The great thing of server integration, that's server side rendering is very friendly for NextJS.

And also is SEO frendly.

But there's list some limitation here.

While we're doing so as our rendering, you will require some backend knowledge.

The next way of implementing Micro frontend will be at the edge side.

If people familiar with AWS Lambda at the edge that you can do micro frontends at the Lambda at the edge as well.

The good thing of doing the integration in edge site is you got very low latency is because of benefits of distribute edge servers providing by AWS.

And also got very great scaling.

However, the limitation about this, the, since we're using Lambda at this time, so we've got very limited CPU limited memory and also very small execution times, you can't do very complicated integrations, micro frontend integrations on the edge because it's easy to get timeout.

The next way to integrating micro frontends will be build time integrations.

During build time integration during build time integration is it's not working.

You got very good version controls.

You can control a single version of the components you would like to integrate into your whole applications.

You can lock it to a very specific version of the components you would like to use.

But standing limitation is every time we want to do a component upgrade, you have to recompile the whole applications.

In these times, tester may not be quite happy because every time we even do a very small upgrade, the whole application got re compiled, which means tester may have to do the whole regressions again.

The next place we can integrate micro frontends will be the client side integrations.

And this is the best place I like.

In client side integration we can do micro frontends in two, there's a two approach doing client side integration in the in client side.

The number one is called web components.

I think quite many people familiar with that.

The great thing of doing web components is the micro frontends actually happening in the run times, that's called run time code sharing.

So that the dynamically integrates the remote on the client's browsers.

It allows teams to deliver their features independently.

It sounds great.

However, there's a couple of limitation here as well.

First, because of using web components, TypeScript is not a builtin features with web components back.

It a big challenge, but it's still achievable of doing some actual work for web components to support TypeScript, but that's not a builtin features.

As well as using web components, there's no shared dependency.

That means if the same page, you have two web components, both of them with React your browsers have to download two React into the browsers there.

They don't share the React automatically.

The will be some actual work you can, make it shared, but bilateral is not shared.

Well, next one, this one is I used to build my product that's called Module Federations.

How many people heard about this?

Oh, great.

Easy.

So Module Federations, they have the two benefits coming out from the, from web, from the web component, but as well as they got built in types with supported.

Great.

And other one one, is you can share dependency as well.

The limitations about Module Federation is that it doesn't have built-ins versioning, but that's not a big deal because everyone use GitHub here.

They got very great versionings.

Now I can see people start, ask questions.

David, you have shown me about five different way to integrations or to integration, micro frontends.

What will be the way I should choose?

How can I choose?

The answer is quite straightforward.

If your product or your application is SEO sensitive, which like you really like to have very good Google search, you would, I would suggest you to use server integrations for, example, like ABC News.

They really relies on a Google to show their lives or you're selling product there.

Then choose server side integrations.

If you think about version controlled, it's important to your product.

You wanna control every single update you want to integrate into your product, go with the build time integrations, and for all the rest, I will suggest you to use client side integrations because that gives very great user experience.

I've gone through the concept there, why?

The challenges.

micro frontends are trying to solve.

And about what is micro frontends and how are we going to implement micro frontends.

I think it's now a good time to talk about, show you some codings.

The code shown in here is based on Module Federation 2.0.

Module Federation 2.0 was announced or released about half years ago in April of 2024.

In this release, it will, it got very two great upgrades here.

One is it got TypeScript supported.

It's built in square, supported.

Second one is called federation One runes.

What is federation run time?

Federation.

run time means they registered and load the remote in the browser.

Let's look at the, to, enable module federation.

There are two plug ins, you have to install.

The sec, the first one is quite straightforward.

The second one, people ask why does it use, esbuild ? That's what coming from the offshore website, you don't have to use that.

It's fully support web pack and esbuild as well.

And the second little thing you have to do is change the index dot ts file to asynchronous.

And I can see, people will ask me why I have to make this dodgy change?

It's not quite straightforward.

The wisdom behind this change is because module Federation happening in the browser.

They're asynchronized, they imported with remote modules.

Only when the client list that having this little change, it help the clients.

It will not know the page or we will not know the remote it doesn't use.

Now that look at some config about module federations.

The three important config when we try to do model federation, the first one is called expose.

define a resource we would like to share . You can share your components.

This is where the place you wanna share your ER components.

But what else other than ER components using Model Federation can also share business logic as well.

And you can share domain functions as well.

Like the the first two here, the host module and host service.

We are trying to share the business logic and specific functions for the with most to reduce.

Also you can share stores.

People using React you want use stores, you use state management neither with x. Using Module Federation, you can share the stay measurements across your whole applications.

So make the datas, make the state, make the data inside of stores the consistent for the whole applications.

Let's lock the end.

You can also share your hooks as well.

Share your hooks to your, to do it most to reduce the business logic so you change the logic in your components.

It will ultimately get pushed out to the whole applications.

Last but not least, you can even share themes.

You can share your styles as well.

Teams with Material UI, you are familiar with themes.

You can share the themes to your remote and that get re used.

You update your colors in the themes, it will automatically get pushed to all the remote.

We have defined the  exposed.

Exposed define the resource you will like to share with most.

It define the resource you will like to consumed.

In this case, I would like to consume the components coming from the common package.

I would like to consume the button.

Usually we define the buttons that had us, the modules, the look and like in the common package, and then we can share that in here.

We can say, I want to consume those from the common package, and we can also consume the whole page from the remote.

The next one we want to define most important is shared.

Shared define dependency you would like to reuse.

That's where we say in the whole application, we only have one React running.

Even all your remotes that using React.

But this allow you to share that React among multiple remotes and you can decide a versions.

That's why React 14 could works well with React 18.

If there are two React 18s using, you can define as singletons.

So there's only one React 18 will be running on the browsers.

Now let's go to how we're gonna use those remote.

Remote will be import using asynchronized leads.

This best practice is to wrap that with, React Lazy that allows those remotes or those remote components to be load only when it's needed.

Error boundaries.

That's how we isolate errors.

Next one is TypeScript.

As I mentioned in Module Federation, 2.0 TypeScript is builtin supported.

TypeScript definition is auto generate when we running a Yarn build or Yarn run.

That's the TypeScript files that auto generate for you and get automatically shared to youll your remote.Ode.

So when you bring up a project in your IDE, you will see the type hint for TypeScript people.

We love the C type hint because that give us kind of certainties.

Into this sutuation I'm not just sharing about the knowledge about micro frontends and Model Federations.

Actually, I've used that in the products my manager asked me to build.

This is the file management systems I built using micro frontend.

You will see on the left side the menu there, you've got multiple menus.

You've got like entities, documents, categories, connections, contacts, and users.

All of them, they're remote.

All of them they connect together and build a product.

And this is this chart generates by Module Federation 2.0.

In this chart it does show a good view of the host, which the homepage of the application, it connects to eight different remotes.

And in each remote, it's a bit too small here, it shows what the remote exposed and what's the, dependency each remote they shared.

If you are starting to use Module Federation2.0 you can download these extensions in Chrome and it give you a very good chart about how your remote and how the host connect together.

And this is the deployment pipeline.

As I mentioned, you can see all those remote and all those functional page, they can deploy independently.

Somewhere we can create a page like the document page.

It takes about one minute and 43 seconds to build.

While some smaller page, like the profile page, they only takes 40 seconds something.

But the good thing is all this they can deploy to independently.

So thank you guys.

Let's do a quick recap to what I have covered to date.

First, when to use micro frontends.

If you are use, if you're working on the middle or large applications, or your application is a multiple page, then that's the time you can consider to use micro frontends.

If you are working on multiple team environments, you want to reduce the overlap or team conflict between other teams, and each team would like to choose their own technical stack.

That's a time you can consider to use micro frontends.

Last but not least, if teams that require to ship feature independently, you are working in one team, but that team got 20 developers, you want to be able to ship feature independently.

That's the time, that's the moment you can consider to use micro frontends.

Using micro frontends there's other benefit as well.

You can have a mixed technical stack, you can use Angular and React together.

You can have legacy page running React 14 while the latest page running React 18.

You can have shared components and shared dependency.

Regarding implementations, if your application is SEO sensitive, use server side integrations, if version control important for you, you can use build times.

Otherwise, I'll suggest use the client side integrations.

And then I show you something about the Module Federations.

Module Ferderation 2.0.

You have built in TypeScript safety and also have federation run times, and we talk about the important concepts about exposed runtimes and shared.

Okay guys, I would like to connect to each other.

So the QR code in the middle is my Linkedin.

If you, feel today's material is interesting for you, you can scan a QR code on the right hand side and put your name down and you can get, you can download the slide.

Any questions.