All we know about Microservices, which helps to develop, deploy and maintain applications individually. Like Uber where booking and payment service...
For further actions, you may consider blocking this person and/or reporting abuse
How do you deal with talking for each sub-frontend. If I want to pass state to another sub-frontend. Putting all the states to the main/parent application will be bad design i guess, and it will not be scalable.
We are currently using Micro Front-Ends for our application. It makes sense when you have a large application that accesses different domains. Each Micro Front-End is it's own independent team and the team is cross-functional. I would try not to share state between the Micro Front-Ends, but if you need to pass data from one to another, I would pass the least amount of data possible and let the retrieving Micro Front-End get it's own data. If you are sharing state between all Micro Front-Ends, you could use session storage but again I would limit the data being stored/passed.
Awesome.
What is this use case for this kind of solution?
Consider you have own Website, having Home, About, Contact Us, Blogs, Service Section.
Instead of keeping all modules in one react application, Create Separate Applications and Merge into a Main Application.
Here, You have Blogs Section, You can create Separate React Application for Blogs and Use it inside main React Application.
Look at the introduction chapter of the book “Microfrontends In Action”. It is about independence teams building independent microfrontends that are composed into one UX for the users. So it’s about scaling up to many semi-autonomous teams who can deploy independently without a big integration of many developers into a “mega-app” which is hard “at scale”.
That's pretty cool. I'm curious about the performance advantages using micro frontends.
One of the best use cases is if you have an application with multiple modules. For example: an application that deals with invoicing may also have receipts, modifying an invoice, and more. All that can be contained in a frontend. Later, you may want to support reporting. Reporting may require multiple pages of its own. For reporting, I would consider a separate front end, just to keep the context of the code small. Interesting pattern
Is this approach better than the module federation approach ? especially considering that using the module federation approach we can share the common npm packages when running the apps within the container thus reducing the bundle size.
@kpiteng is this approach better than the web pack module federation approach ?
also in Module federation approach we can kind of can share the the common npm packages without increasing the bundle size. is it possible via this approach ?.
Why can't I use props children in micro frontend, I'm moving my entire react application to micro frontend, I'm using props children in few places mostly when I'm using useContext(), but seems like I'm unable to access children in props
Take a look at the book “Microfrontends In Action” that discusses exchanging state.
Essential the approach doesn’t come “for free” in terms that “fragments” as the book calls them are more “isolated” from each other than a normal app. So two things come into play: if they are closely related they should probably be in the same “frontend”. If they are truly two separate “fragments” that should be owned by different dev teams and deployed independently (which is the whole point of doing microfrontends) then you need to look at specific details of what to send “events” between the fragments that they can respond to.
I am currently looking at what the different options are for that. In some of our cases sending events via the backend makes sense for a few of our use cases. Just because the reason we need to update many fragments on the UI is exactly because the uses have pushing work to the server.
In other cases it’s is truly the case that we want to sync state across the fragments without any writes to the server. In which case the book discusses that.
Hi. can i use lazy load, in a microfrontend app. why i ask this question because one of the rule of the microfrontend app is: when the container app tries to load the MFE, everything should be in one JS file, so we must disable the chunking. if this is true how the lazy load work??? if the chunking file will be disabled and everything should be in one JS
but isn't this what the code splitting of react does ? with the use of Suspense and lazy load. the bundle size reduces anyways .. what is the exception in this method of implementation when compared to code split ?
so, you did not push commits, I don't see react-app-rewired changes
and it looks like it's mostly inspired by
blog.bitsrc.io/how-to-develop-micr...
react-app-rewired are there in web-app-blogs and web-app-header application.
I am curious to know, what about a situation where one of the microFrontnend host have issue responding, what ways can you handle that considering the user experince?
You can display an error message if there is an error loading the Micro Front-End.
Excellent explanation @kpiteng , I was wondering how to deal with the routing to render each microfront this is why I came here. Thank you very much for this guide.
As I have learnt, this pattern can be useful for development purpose beacuse it's easy to maintain & pretty clean code. How about app performance ?
App Performance will be faster because your app divided into multiple web apps according your requirement so bundle size reduced and performance increased.
Hi. Is there a way to preload or to load faster the micro frontends ?
I just tried to use context here, but unable to get context values in remote component.