At a previous job, we tackled micro front ends by basically having a some shared header code, which was written in plain JavaScript html, hosted somewhere; this was injected into the page on load and rendered. The header had all of the links to the various micro uis, and each micro Ui was built and deployed individually by different teams. Some of the stuff you mention sounds like you took it to the next level (which is cool) such as having sub components of pages loaded and rendered via xhr request. I’ve switched projects since then, but it was a cool learning experience! Thanks for the video
This video made me realize, I was part of a micro front end team in my previous job 🤣. We had a mono repo for our micro frontends and we shared each other's teams reusable code by developing private npm packages for sharable code like UI libraries. We had micro frontends within a micro frontend if you consider loading different page sections in s which was crazy at first.
Greetings from Redmond, WA :) Thank you, your videos are awesome! I spent the last few hours binge watching your playlist. Nice to see how far the industry has come along. Back in 2015, I worked at Microsoft and we built a proprietary micro-frontend for Azure.
Thanks for this great video. I worked at a small company that used Web Components that got slotted into a React app. The React app was tiny as a result. We didn't use the term "micro front ends" but what we had basically meets your definition. I'd argue that this is definitely a standard. Certainly not a "Redux of MFEs" as you say, but still a viable standard, especially considering the variety of tools that can stamp out Web Components if you don't feel like rolling your own.
This is awesome. I’ve been writing config based code for the last 3 years and finally something comes out that is going to make this style the norm. I can’t wait for this to happen.
@@chenrvn Man, if you could get me a working gRPC example to work off of I would be much appreciative. I tried for a couple of days a few months back and could just not get it going!
@@jherr Here is an example for 2 nest js client-server gRpc communication :) - i don't have an example of a pure SPA client-side app (but maybe I will create in near future :)) here are the repos: - client: github.com/ChenReuven/nestjs-grpc-client-sample - server: github.com/ChenReuven/nestjs-grpc-server-sample
A really helpful video! I like that you presented both the aspects (pro and cons). This way, you will better know when it's a good idea to use it and when it's not.
Really a good short and precise video, doing exactly what the title said it would do. And I'm now confidant that MFE is the wrong path for our current project. 👍
The first 3 minutes of this video makes me think of components in a React app. Components are individual blocks of code that do something. The code for such components are often found in 1 file among a collection of other components.
I did implement micro apps by in react until i meet with this channel, To communicate with parent and children was really tricky and messy in Iframe. thank you!
Thanks @Jack Herrington for making MF such easy way to implement. Currently, I am struggling with "Cross micro frontends communication" with mono angular MF, through a common/ shared service between all the MFs. I hope, I am not alone, Many of us going through same challenge, If you could share any article/ video. From there we can take reference. Thanks in advance. I am waiting for hear something from you.
I watched this mfe THEORY video right after watching your mind-blowing mfe PRACTICAL video ("Micro-Frontends in Just 10 Minutes") -- which really helped convince me of the WHY. 👏 🤜🤛
Awesome! Are you planning to make a tutorial on micro-frontends? I would love to see a nice app split in micro-frontends, with routing, auth, and some code sharing
I assume there is a number of different ways to identify "targets" for MFEs, so I would really appreciate your thoughts on this. In the video, you pointed out the "carousel" being a good target for an MFE which makes sense, and I would consider that to be something like a "feature-level" MFE. When hearing/reading recommendations from Luca Mezzalira (who also seems to be a huge MFE advocate), he seems to lean more towards the idea of separating MFE targets at to "domain / sub-domain" level. In the Amazon example, I think that would mean the "cart" would be MFE, maybe "Orders" would be an MFE, and so on. To me, this model makes a lot of sense as it supports the constraints of an organization. I feel that within an organization, you would have teams of developers, business analysts, and data scientists focused on optimizing the "cart" experience, so having an MFE that a single team owns and specializes in makes a lot of sense to me. With the carousel example, I cant really see a single team really "owning" that MFE and I am uncertain how that "feature-level" targeting could be sufficiently delegated amongst a series of teams in an organization. Would love to get your thoughts and if there is an MFE framework that fits the "domain/sub-domain" approach Thanks in advance! I just discovered your channel today and just want to say I love the way you explain things and I subscribed right away!
I think SingleSPA is really intentioned to be a domain/sub-domain solution. Their primary use case is to manage the SPA at the route layer, though they do support making "drop-in" MFE components as well (e.g. cart or the add to cart CTA). The product carousel example is probably bad in that it's pointing at an implementation and not a feature. Ideally you'd have a team that would control product recommendations, including the API, the data analysis, modeling, and recommendations algorithm, as well as getting that represented in the front end as a Product Recommendation Carousel MFE. And in that case, it's definitely a team, or several. And then from a scrum team perspective that team would own their conversion metrics around that feature, and optimize accordingly (e.g. let's A/B test a carousel versus a slider, or whatever). And the host page doesn't care either way, it just drops the MFE on the page. Thanks for the subscription. I've wanted to do another high level video like this on GraphQL. Would you be interested in that?
@@jherr Wow thanks for the excellent reply. Your points about the carousel definitely make sense when applying that level of depth, so I see now how a carousel could certainly stand-alone as a MFE with a full team behind it. I was simply perceiving it as an import that took props :) But your description definitely makes sense. I would love a video about GraphQL - Personally Ive only used it on Gatsby implementations, and I feel a majority of GraphQLs power is hidden behind Gatsby's build process - so I would love to learn more about it and how it could be applied to more of my projects
@@Poomastafatz Cool. Well, this one one be more for the product manager types who are like "Why should I prioritize this 'Port to GraphQL' ticket? We already have a REST API." But it would also be a decent overview.
Just started my first job and we’re considering adopting microfrontends for the various apps across the platform. It’s an interesting concept but I have a hard time distinguishing them from components.
They are implemented as components but imported as a run-time dependency as opposed to a build time dependency. That means that they can be updated separately without re-deploying the application.
for short, it looks like microservice in BE side, where you can combine many different technologies and make them work together without any issue about compatibility, you can combine Vue, React, Angular together in micro FE like when you use Golang and Python and Nodejs together to build a good backend, hope that helps
It’s interesting to understamd how these microfrontends are hosted. Is that when you build the project everything is in the build or they are built and hosted separately and just injected into the hosted pages?
Might be a stupid question, but say you have a Design System / Component-Library / UI-Kit that lives within a Monorepo alongside, let’s say an AppShell (Host App), products page and a cart page. All of them are MFs and all of them consume, let’s say the ButtonComponent from our component library. Does the code of the Button gets baked into each and every MF resulting basically in duplicated code and larger bundle per MF? Or would you have to setup each and every component of the library as own MF to be able to consume it without duplication (resulting in a lot of request - because you other stuff out of the library too). Or is there a chance that the shell imports the UI-Kit and kind of exposes all it’s contents (wildcard expose?!). I really enjoyed the video - like all your other stuff ✌🏻❤️
Hi Jack Thanks for a great intro video on MFE. It really helped understand the concept. However, I do have a question We were always consuming other web portals into a host website using s or something similar. How ar MFEs differeent from these?
What is something similar to an ? An is a decent mechanism for this but there is a high level of isolation between the host page and the . For most uses an MFE framework that allows for a higher level of integration with the MFE code and the host page code is better. You can get away with less CSS as well and the content appears better integrated.
Cool video! Do you see MFE platforms in the future being actual servers/services that are maintained by a platform team, or will they be more likely to leverage things like lambdas@edge for cloudfront or edge workers for akamai?
I think an infra team should manage the API surface of MFEs for a given company or portion of a company so that everything is consistent. But how those MFEs are deployed, as long as the MFE surfaces conform to that API, should be up to the team. Server based, lambdas, or static, all of that should be supported. The infra team should also maintain a test harness app that MFE development teams can use to ensure that they are playing nice in the ecosystem. And thanks for the subscribe!
@@jherr thanks for the fast reply! What kind of things are you thinking of when you mention contracts? SLA's, shared `window` resources, analytics apis, and etc?
@@knownawol Lifecycle events (e.g. mount, unmount), and properties (and property changes if that's supported). That would be the base level. And then optionally; versioning, data requirements (e.g. I need this GraphQL query fragment), analytics, perf logging, shared data (e.g. user identity, cart count), or a shared event bus. But what you decide to do or not do should flow from an analysis of what parts of what pages should be MFEs, and then the minimum set of requirements to get that done.
I have a question. We're working on a POC app at work and we use microservices and microfrontends for the architecture. We are dockerizing everything, every microfrontend and microservice. How would you go about having the different microFE containers communicate with each other? Any blogs, forums or vids will help. Basically any rresource XD
There is our book module-federation.myshopify.com/ . :) And that covers a lot of state managers and such. POCs with Docker are ok, but in production you'll want to have your federated modules deployed to an asset store like S3.
I have a question. We're working on a POC app at work and we use microservices and microfrontends for the architecture. We are dockerizing everything, every microfrontend and microservice. How would you go about having the different microFE containers communicate with each other?
There is our book module-federation.myshopify.com/ . :) And that covers a lot of state managers and such. POCs with Docker are ok, but in production you'll want to have your federated modules deployed to an asset store like S3.
@@jherr ok. SO the thing is were working on the POC as like, you know a proof of the concept... We will be using it as our architecture for a v3 of our CMS system. We'll most likely be using Azure to host the fed mods. So you'd have like all your microFE just plug into your fed mods in Azure?
@@rubenverster250 You should take this conversation over to #module-federation on the Discord server. But in short, federated modules are just JavaScript files and should be deployed like any other JavaScript modules. The same way you would deploy the bundle of an application to S3 (or the Azure equivalent).
Hi, thanks for the explaination, my query is regarding is it possible achieve single spa of MF1 of AngularJs and MF2 Angular 9+ in vanilla JS root container or something like root-container will be Angular 10 or 13 and exposed MF's ie. AngularJs and Angular 2+ ? If it is possible please help to understand.
I think that's possible. But Angular is not my area of expertise. Feel free to log onto my Discord server and ask your question there in the #module-federation channel, but be sure to read and follow the #rules before posting.
Personally I would mock all the remotes. You unit test against the contract with the remote, not the implementation. For a complete test you can use traditional E2E tools.
loved this channel...you're awesome..!! Just one request, Would it be possible for you to share your views and guidance on micro frontend with React + Redux + Redux Toolkit ?? Specifically managing the global state and inside the sub apps, plus how the communication works with subscriptions
First came applets, then portlets, then widgets and now micro frontends. The concept has been the same but the architecture behind changed a lot for good.
How do we handle sharing libraries? What about one MFE running react 1.16.x and another with 1.16.y? Seems to me that the bundle would be huge, no? I'm working on a project that would benefit from this approach given that we could do something about the bundle size. But I'm still not convinced that it's worth the complexity. This, just like micro services them selves seems like it comes with a great cost in complexity.
Webpack 5's Module Federation shares the react and react-dom library (and whatever else you need) across the Micro-FEs. And it does a really good job with version arbitration and making you only load what's needed.
"I'm still not convinced that it's worth the complexity." - that's very good actually! Use them only when you clearly see advantages outweigh disadvantages. Just as you compared MF to microservice architecture: microservices are significantly more difficult and, if you don't need them, stick to monoliths for simplicity. However, in some situations, monoliths reach a size after which the cost of scaling your teams or product is not acceptable. When it comes to sharing libraries, apart from Jack's tip on sharing via Module Federation, there's also a rule for microservices (again) which goes: SHARE NOTHING. The thing is: if you have multiple teams that maintain various MFEs and you make them share a dependency, then - whenever you want to change that dependency in a breaking way (e.g. major version bump) - you have to do that in either all of the consumer-apps or none of them. And that's clearly breaking the goal of independent releases. So in ideal world, you'd prefer to share nothing in a distributed system. You might, well, share lodash (only 1 dep in runtime, smaller bundle) if you don't expect it to introduce breaking changes anyhow soon, and reuse it. However, when a breaking lodash v5 arrives, you might want to make your apps use their own lodash versions (copies, bigger bundle) and then the seperate teams could migrate independently. So in this case the tradeoff is: smaller bundle (shared deps) VS independent ops (shared nothing). Common problematic situation in real-life microfrontends is: among many teams, there is a team which maintain internal company component library. It's specific to a certain framework (such as angular material, material UI, etc). The library shares, let's say, 50 components. Now, there are MFEs which use the components as they are right now (most recent versions). But within time, the component library would update their components, break the API at some point (e.g. major material UI being bumped, which breaks API) and some MFEs might decide NOT to update, because they have different business goals. But then, they need to use a component which is available only in the most recent version of the library... and there's a clash: either they update all their components (to enable the new one which they need) or none. You could think of publishing not a whole library, but each component separately - that would allow you to pick certain version of certain component from the lib, but. would introduce a significant overhead on the deployment process, bundle size and complexity. Sharing is troublesome in distributed systems.
With Module Federation you get the ability to multiple projects to runtime depend on code that is pushed once and the projects get that code without re-deployment. With deferred loading you still have to redeploy to push updates.
@@jherr Ok thanks for the clarification ... with current CI/CD systems whenever a code push is happening, also an automatic deployment of the whole frontend can/may happen, and I prefer checking project compatibility at compile time in TypeScript before deployment as compared to just assume compatibility at runtime after deployment ... of course the individual deployment is kept as an advantage for MFEs ... but for me this single advantage is rather weak for the introduced complexity ... I think you can see MFEs just as the microservices pattern ported to the frontend, right?
@@HannesBrantner It's totally fine that you want to use build-time linking and CI/CD. And you are welcome to your opinion on that as an MFE mechanism versus a runtime linking. And yes, I believe the current meta-definition of MFEs as the microservices patterns ported to the frontend. There are multiple ways to do that, even if you personally wouldn't choose some of the solutions.
To be honest, I still doubt the concept of MFE, because I see no established approach or live example, just an ad-hoc sites. How can the MFI manage authentication if each component have its own provider ? how to manage routing ? what if there is shared data between those MFI components ? How can we manage to make MFE components working together when we have fundamentally different approaches like Virtual DOM in React and a compiler for Svelte ?
I started developing websites in the early 90s and did it professionally for about 6 years, then took a 20 year break.... it is funny coming back and seeing that all the headaches have been fixed. I want to make an uphill, both ways, joke
It is kinda funny that Micro-FEs are fixing a problem that the bundlers created. We used to just import JS files all the time off the frontend. Or we would use something like requirejs to do dependency management.
Great video. I can't help but think that micro FE's could be really difficult to manage if you have multiple components that need to communicate with each other. It just sounds like a recipe for disaster to me. But maybe i'm wrong.
IFrames can be MFEs. It's really just a matter of implementation. MFEs implemented using IFrames are genuinely independent and walled off from the page. The JavaScript runs independently. The HTML and CSS are entirely independent. And you have to work pretty hard to tunnel data and messages between the host page and the . "Zoid" is the only IFrame based MFE system that I know of. Other MFE systems, like SingleSPA, or Module Federation, have components that are integrated into the DOM of the host page. So they pick up the local CSS styling and also can be more easily integrated at the JavaScript level.
Single SPA parcels are meant to be self contained in their state. So the host app can use redux. And a parcel can use redux internally. But I doubt there is an elegant way to bridge them. I haven’t tried though.
Although you explained the difference between a library and a micro frontends I just don't really understand what you meant when you said micro frontends are different because they can be deployed independently. So can libraries can't they? I'm not sure what you meant. It's just not clear to me why you'd use a micro frontend over a library and how they really differ?
A library is built into an application. So if, for example, you have your shared header component in a library, and you have five apps, then all fives apps would need to be rebuilt and re-deployed for all a release of the header to be live across the entire site. If your header is a micro-frontend then it's code that is consumed at runtime, instead of built into the compiled app. So, when the header is deployed it is live updated across all the sites immediately.
How do you solve problem of loading same dependencies multiple times for such host page with many MFEs? Say your MFEs are in React, why would you want to force user to load mulitple React instances? Are there any tools to help with that or os this still DIY space?
Module Federation solves that problem by having a Webpack runtime on the page that manages the shared dependencies. So if you've got a host page that has React, and an MFE that use React coming in, then when you ask webpack to load the MFE code it will first look to see if it can share any dependencies, (i.e. React) to avoid having the MFE load its own. That's actually not just an optimization, it's critical because there can only be one React and one React-DOM on the page at a time.
Ah right, Webpack 5 module federation. That assumes all teams must use it to bundle their mfe's using webpack 5, right? Or are other build tools able to "contribute" to client side modules registry Webpack runtime uses?
@@gustaff.weldon Yes to Webpack 5 for the time being. Though you can load WP5 federated modules into a Webpack 4 app. And other bundlers are starting to look at having a module standard that matches that. If you are looking for something entirely agnostic I'd look at Single SPA. But I think in that case, depending on how you use it (because it can use Module Federation as a code transport mechanism) you might be looking at having multiple sandboxed React instances.
Thanks. I think foregoing that bit of build tool choice freedom, to gain so much eg. on user front is not a big price to pay. Single-spa was quite crude when I tested it last year, but one year is hell of a time in FE, so of course things have moved. I'm grokking slowly through your MFE videos to bring myself up to date, so do not be surprised if I dig out some other videos with questions. I'm trying to visualise what a possible MFE architecture for our ever growing SPA might be (and if it even makes sense). I think you're doing a stellar work with those videos. They have that "meat" I like and learn from. Thanks
@@gustaff.weldon Ask as much as you like. At the end of the day most projects use a bundler. And that's either gonna be webpack, rollup or parcel in most cases. And way, way, way back Zack had module federation working with Rollup. So it is possible. The actual module federation client side contract itself is not all that complex.
@@sreekumarmenon Gotcha, well, in the meantime, you should check out OpenComponents th-cam.com/video/9CG0LeswOoM/w-d-xo.html and Edge Side Includes th-cam.com/video/4PoNBZl4t0Y/w-d-xo.html . OpenComponents has a server side rendering option, and Edge Side Includes would add the micro-fe HTML, JS, and CSS to the page before it gets to the customer. So both of those would have zero impact on SEO. Tailor (github.com/zalando/tailor) also does server side rendering. The other Micro-FE frameworks I've used (thus far) have been client side rendered. I hope that helps.
If you have ten different teams with different applications all of which deploy independently, which are then knitted together by a CDN provider (e.g. Akamai) then if you want to deploy a header update to all the sites simultaneously then each application would need to rebuild, pull the new package, etc. and deploy simultaneously, which is a challenge to say the least. In a Micro-FE approach all the applications are loosely coupled to the applications so they all get updated simultaneously.
Good point, thanks! I get it now. I only thought about a single website with multiple MFE components, not the multiple sites/pages maintained by different team scenario.
@@Somethingwronghere No problemo. That's just one scenario. The other is when you have a SAAS company that wants to provide hosted widgets for use on external uncontrolled pages. Back in the jQuery days we used to call these "widgets". Micro-FEs are a similar/same concept.
You could do an emotion theme if you could carry that context through to all the MFEs. Or you can do a common stylesheet. Or you could do a common stylesheet where the MFE injects any additional styling. There are ways, but yeah, it's not OOTB.
Is it possible to create micro frontend in diffrent framework and render it in one single page application with module federation if yes how to do that configuration Please help
Ah, jeez. Everything old is new again. I was at a company building re-usable server side components in early 2000s for various industries, which would embed in their web pages. Now, just because we're moving *some* code to the front end we're suddenly using the "micro-frontend" buzzword. People were doing this crap with s since the year dot until that was disparaged.
Not just s, things like jQuery components as well. We lost the ability to do this when we went with bundlers. But, as it turns out, in some cases you need that runtime dependency support.
@@jherr i just wanted to know how can I start project with pure javascript is there any reference which you can share with me, I dont want to use js framework need to use pure javascript with JQUERY
It is overkill for small teams or small projects. Micro-FEs are more of a large company, large architecture thing. If you have multiple applications managed by multiple teams, and they need to share UI component at RUNTIME, then Micro-FEs are the way to go. If you don't need that runtime element then there is no need to pay for that complexity.
It is a component, but is integrated as a runtime dependency so that it can be deployed independently. In addition it can be packaged in a way to make it usable across different view frameworks (e.g. React components on a Vue page, etc.) This is best accomplished using Single-SPA.
I see that you haven't touched micro frontends much after this time period(2-3 years ago), is it that they're not trendy anymore and monorepos are the new thing, or is it that there's nothing more to talk about them?
Everything that the micro frontend approach brings to the table can be done via a monolith. That being said, vast majority of people structuring that monolith do it in the technical domain rather than the problem domain. Generally speaking they do not think about issues like extendibility, maintainability and parallel development. The basic architectural concept you are describing is decoupling, which is essential for highly resilient near endlessly extendable applications. When it comes to multiple js packages, 2 x 5MB js files are significantly worse than a single 20MB js file (well .. technically not cz 2 files do download simultaneously, but). Latency is much more of a problem than download speeds. That is the case since the late 2000's. There is nothing innovative or revolutionary about the modularity of a given project. The ideas behind it where known since the 60's. However, the industry as a whole takes React, Redux, mUI, scss, reducers, vue, the main menu, etc... as THE problem of a UI, not the actual problems which the app should solve. Hiring practices fully reflect this. The internal structures of companies fully reflect this. The hundreds of libraries tailored to help with the side effects of inadequate architectures reflect this perfectly. You have all my thx trying to beat some sense into people but I think we are up against a dragon we cannot slay.
A monolith? Not necessarily. If you have 100 developers on your project, so say 10 different teams working on different sub applications, I don’t think it makes sense to have to redeploy the entire monolith application just to fix a bug or add a feature for users. The issue with monoliths is because as a system gets larger, it’s very difficult to deploy changes; builds take longer, automated tests take longer, manually verifying an application takes longer, and there being a much higher risk someone from one team broke the app for everyone else.
@@WebDevCody If I am developing that app you can bet there wont be deploy issues or breaking errors for over 350 screens with heavy data processing. Not because I am such a brilliant programmer but ... lets say I have try-catch on some pure code (independent of volatile data, like server returns). I also make heavy use of pure html nodes which has little to no effect on deploy speed. However, Its not just me, obviously. And the risk you are talking about is quite real, regardless of the size of the core (core: code which has afferent couplings across the entire app). One team under a joint pattern does not warrant micro frontends. Multiple, however, yes. You can't maintain discipline for multiple teams. If you have 100 frontend developers on a project, I wont touch that with ten foot pole.
"Everything [...] can be done via a monolith." No. Don't generalize, not _everything_. Real-life example: Your company acquires other companies with systems built on top of completely different toolstacks (i.e. different frameworks), and those systems are really huge. And the dev teams are spread all over the world, each already maintaining one of the sub-apps. And your task is to "merge" them into a single system, and it makes a lot of sense from business perspective. You won't rewrite them into a uniform toolstack (way too expensive). You can put them into a single repo, but this doesn't change anything, you NEED the teams to work separately on each sub-app. Welcome to micro-frontends.
Micro frontend concept is created by architect, not developer. The architect try to educate developer how to implement a vision he has, but the he doesn't know how to do it. It is politics, chaos, mess. It is vietname war that you can't win.
Hi, thank you for great video! I think you might be also interested in this... We just shipped initial version of the Isomorphic Layout Composer, complete solution for Micro Frontends composition into SPA with SSR support. github.com/namecheap/ilc
![[ENGSUB] UNPRODUCTIVE DAY ใช้ชีวิต (เปื่อยๆ) ด้วยกัน 1 วัน! | OUROAD CLOSEFRiEND SS2 EP.9](http://i.ytimg.com/vi/pyYKZ3kra9w/mqdefault.jpg)
At a previous job, we tackled micro front ends by basically having a some shared header code, which was written in plain JavaScript html, hosted somewhere; this was injected into the page on load and rendered. The header had all of the links to the various micro uis, and each micro Ui was built and deployed individually by different teams. Some of the stuff you mention sounds like you took it to the next level (which is cool) such as having sub components of pages loaded and rendered via xhr request. I’ve switched projects since then, but it was a cool learning experience! Thanks for the video
This is super interesting. Did you have any considerations around SEO/pre-rendering etc? I’m wondering how that would be handled in an MFE project
this channel deserves some love ❤
Quality content, it will grow!
This video made me realize, I was part of a micro front end team in my previous job 🤣. We had a mono repo for our micro frontends and we shared each other's teams reusable code by developing private npm packages for sharable code like UI libraries. We had micro frontends within a micro frontend if you consider loading different page sections in s which was crazy at first.
that made me laugh out loud at office
Man.... you are KILLING IT. Keep up with great work!
Greetings from Redmond, WA :) Thank you, your videos are awesome! I spent the last few hours binge watching your playlist. Nice to see how far the industry has come along. Back in 2015, I worked at Microsoft and we built a proprietary micro-frontend for Azure.
I just want to say Jack, you're awesome! Your ability to break things down and explain they "why" to any technology is uncanny. Keep it up!
Thanks for this great video. I worked at a small company that used Web Components that got slotted into a React app. The React app was tiny as a result. We didn't use the term "micro front ends" but what we had basically meets your definition. I'd argue that this is definitely a standard. Certainly not a "Redux of MFEs" as you say, but still a viable standard, especially considering the variety of tools that can stamp out Web Components if you don't feel like rolling your own.
Thé information is 1 year old and still relevant. Thank you.
Take a shot every time he says micro-frontend / MFE. All jokes aside, I love your videos.
This is awesome. I’ve been writing config based code for the last 3 years and finally something comes out that is going to make this style the norm. I can’t wait for this to happen.
Nice one! We need more of these to lower the barrier to entry for MFE adaptation. Especially with the tech catching up
Yeah, I've been thinking about doing one of these about GraphQL. Trying to explain the importance of GraphQL for non-technical folks.
@@jherr maybe some gRpc connection magic :-)
@@chenrvn Man, if you could get me a working gRPC example to work off of I would be much appreciative. I tried for a couple of days a few months back and could just not get it going!
@@jherr Here is an example for 2 nest js client-server gRpc communication :)
- i don't have an example of a pure SPA client-side app (but maybe I will create in near future :))
here are the repos:
- client: github.com/ChenReuven/nestjs-grpc-client-sample
- server: github.com/ChenReuven/nestjs-grpc-server-sample
A really helpful video! I like that you presented both the aspects (pro and cons). This way, you will better know when it's a good idea to use it and when it's not.
Thank you, there are many helpful videos from you about MFEs.
Really a good short and precise video, doing exactly what the title said it would do. And I'm now confidant that MFE is the wrong path for our current project. 👍
That's ok, MFEs are not a panacea.
This is a good Intro. You should share more examples or tutorials on how to begin with Micro Frontends.
Here is a playlist - th-cam.com/video/XUtCnA9WEgQ/w-d-xo.html&ab_channel=JackHerrington
MFE will be the future for remote team.
Thank you for your contribution to the Software community. 👏 Your videos are awesome
The first 3 minutes of this video makes me think of components in a React app. Components are individual blocks of code that do something. The code for such components are often found in 1 file among a collection of other components.
I did implement micro apps by in react until i meet with this channel,
To communicate with parent and children was really tricky and messy in Iframe. thank you!
Excellent video. The way you broke this concept down made it very simple to understand.
Thanks @Jack Herrington for making MF such easy way to implement.
Currently, I am struggling with "Cross micro frontends communication" with mono angular MF, through a common/ shared service between all the MFs.
I hope, I am not alone, Many of us going through same challenge, If you could share any article/ video. From there we can take reference.
Thanks in advance. I am waiting for hear something from you.
I watched this mfe THEORY video right after watching your mind-blowing mfe PRACTICAL video ("Micro-Frontends in Just 10 Minutes") -- which really helped convince me of the WHY. 👏 🤜🤛
th-cam.com/video/s_Fs4AXsTnA/w-d-xo.html
^ "Micro-Frontends in Just 10 Minutes"
Thanks @Jack, It is something that I wanted to hear about micro frontends.
my God the video and audio quality, lightings and editing is just awesome!!
Awesome! Are you planning to make a tutorial on micro-frontends? I would love to see a nice app split in micro-frontends, with routing, auth, and some code sharing
This is such a great video - so well done and thought out
Thank you sir, Gold content 🙏.
It was just great and clean like yourself
Awesome explanation. Thank you.
Thanks Jack, it helped me a lot
I assume there is a number of different ways to identify "targets" for MFEs, so I would really appreciate your thoughts on this. In the video, you pointed out the "carousel" being a good target for an MFE which makes sense, and I would consider that to be something like a "feature-level" MFE. When hearing/reading recommendations from Luca Mezzalira (who also seems to be a huge MFE advocate), he seems to lean more towards the idea of separating MFE targets at to "domain / sub-domain" level. In the Amazon example, I think that would mean the "cart" would be MFE, maybe "Orders" would be an MFE, and so on. To me, this model makes a lot of sense as it supports the constraints of an organization. I feel that within an organization, you would have teams of developers, business analysts, and data scientists focused on optimizing the "cart" experience, so having an MFE that a single team owns and specializes in makes a lot of sense to me. With the carousel example, I cant really see a single team really "owning" that MFE and I am uncertain how that "feature-level" targeting could be sufficiently delegated amongst a series of teams in an organization. Would love to get your thoughts and if there is an MFE framework that fits the "domain/sub-domain" approach
Thanks in advance! I just discovered your channel today and just want to say I love the way you explain things and I subscribed right away!
I think SingleSPA is really intentioned to be a domain/sub-domain solution. Their primary use case is to manage the SPA at the route layer, though they do support making "drop-in" MFE components as well (e.g. cart or the add to cart CTA). The product carousel example is probably bad in that it's pointing at an implementation and not a feature. Ideally you'd have a team that would control product recommendations, including the API, the data analysis, modeling, and recommendations algorithm, as well as getting that represented in the front end as a Product Recommendation Carousel MFE. And in that case, it's definitely a team, or several. And then from a scrum team perspective that team would own their conversion metrics around that feature, and optimize accordingly (e.g. let's A/B test a carousel versus a slider, or whatever). And the host page doesn't care either way, it just drops the MFE on the page.
Thanks for the subscription. I've wanted to do another high level video like this on GraphQL. Would you be interested in that?
@@jherr Wow thanks for the excellent reply. Your points about the carousel definitely make sense when applying that level of depth, so I see now how a carousel could certainly stand-alone as a MFE with a full team behind it. I was simply perceiving it as an import that took props :) But your description definitely makes sense.
I would love a video about GraphQL - Personally Ive only used it on Gatsby implementations, and I feel a majority of GraphQLs power is hidden behind Gatsby's build process - so I would love to learn more about it and how it could be applied to more of my projects
@@Poomastafatz Cool. Well, this one one be more for the product manager types who are like "Why should I prioritize this 'Port to GraphQL' ticket? We already have a REST API." But it would also be a decent overview.
Very usefull , God bless you !
Thank you for the video!
Just started my first job and we’re considering adopting microfrontends for the various apps across the platform. It’s an interesting concept but I have a hard time distinguishing them from components.
They are just remote components. But don't use them unless you have a compelling need for them. And don't use them for mission critical UI.
So how do MFEs differ from Components in React? Aren't they basically the same?
They are implemented as components but imported as a run-time dependency as opposed to a build time dependency. That means that they can be updated separately without re-deploying the application.
@@jherr Ahh ok, thanks for the explanation!
for short, it looks like microservice in BE side, where you can combine many different technologies and make them work together without any issue about compatibility, you can combine Vue, React, Angular together in micro FE like when you use Golang and Python and Nodejs together to build a good backend, hope that helps
your videos are gold
Thanks for this video!
one of many great videos
It’s interesting to understamd how these microfrontends are hosted. Is that when you build the project everything is in the build or they are built and hosted separately and just injected into the hosted pages?
This voice is nice to listen to
Might be a stupid question, but say you have a Design System / Component-Library / UI-Kit that lives within a Monorepo alongside, let’s say an AppShell (Host App), products page and a cart page.
All of them are MFs and all of them consume, let’s say the ButtonComponent from our component library. Does the code of the Button gets baked into each and every MF resulting basically in duplicated code and larger bundle per MF?
Or would you have to setup each and every component of the library as own MF to be able to consume it without duplication (resulting in a lot of request - because you other stuff out of the library too).
Or is there a chance that the shell imports the UI-Kit and kind of exposes all it’s contents (wildcard expose?!).
I really enjoyed the video - like all your other stuff ✌🏻❤️
No, the host app exposes the component-library and the MF modules can then use it from the host app's bundle.
Hi Jack
Thanks for a great intro video on MFE. It really helped understand the concept.
However, I do have a question
We were always consuming other web portals into a host website using s or something similar. How ar MFEs differeent from these?
What is something similar to an ? An is a decent mechanism for this but there is a high level of isolation between the host page and the . For most uses an MFE framework that allows for a higher level of integration with the MFE code and the host page code is better. You can get away with less CSS as well and the content appears better integrated.
Nice overview - thanks
Cool video! Do you see MFE platforms in the future being actual servers/services that are maintained by a platform team, or will they be more likely to leverage things like lambdas@edge for cloudfront or edge workers for akamai?
I think an infra team should manage the API surface of MFEs for a given company or portion of a company so that everything is consistent. But how those MFEs are deployed, as long as the MFE surfaces conform to that API, should be up to the team. Server based, lambdas, or static, all of that should be supported. The infra team should also maintain a test harness app that MFE development teams can use to ensure that they are playing nice in the ecosystem.
And thanks for the subscribe!
@@jherr thanks for the fast reply! What kind of things are you thinking of when you mention contracts? SLA's, shared `window` resources, analytics apis, and etc?
@@knownawol Lifecycle events (e.g. mount, unmount), and properties (and property changes if that's supported). That would be the base level. And then optionally; versioning, data requirements (e.g. I need this GraphQL query fragment), analytics, perf logging, shared data (e.g. user identity, cart count), or a shared event bus. But what you decide to do or not do should flow from an analysis of what parts of what pages should be MFEs, and then the minimum set of requirements to get that done.
Thanks!
I have a question. We're working on a POC app at work and we use microservices and microfrontends for the architecture.
We are dockerizing everything, every microfrontend and microservice. How would you go about having the different microFE containers communicate with each other?
Any blogs, forums or vids will help. Basically any rresource XD
There is our book module-federation.myshopify.com/ . :) And that covers a lot of state managers and such. POCs with Docker are ok, but in production you'll want to have your federated modules deployed to an asset store like S3.
Thanks a lot!
I checked now (2023) and it seems like single spa has significantly more downloads and coverage than any thing else you've described.
youre very charismatic bruh!
I have a question. We're working on a POC app at work and we use microservices and microfrontends for the architecture.
We are dockerizing everything, every microfrontend and microservice. How would you go about having the different microFE containers communicate with each other?
There is our book module-federation.myshopify.com/ . :) And that covers a lot of state managers and such. POCs with Docker are ok, but in production you'll want to have your federated modules deployed to an asset store like S3.
@@jherr ok. SO the thing is were working on the POC as like, you know a proof of the concept... We will be using it as our architecture for a v3 of our CMS system. We'll most likely be using Azure to host the fed mods.
So you'd have like all your microFE just plug into your fed mods in Azure?
@@rubenverster250 You should take this conversation over to #module-federation on the Discord server. But in short, federated modules are just JavaScript files and should be deployed like any other JavaScript modules. The same way you would deploy the bundle of an application to S3 (or the Azure equivalent).
@@jherr big
Hi, thanks for the explaination, my query is regarding is it possible achieve single spa of MF1 of AngularJs and MF2 Angular 9+ in vanilla JS root container or something like root-container will be Angular 10 or 13 and exposed MF's ie. AngularJs and Angular 2+ ? If it is possible please help to understand.
I think that's possible. But Angular is not my area of expertise. Feel free to log onto my Discord server and ask your question there in the #module-federation channel, but be sure to read and follow the #rules before posting.
Thanks for the video. How should you unit test your app?
Personally I would mock all the remotes. You unit test against the contract with the remote, not the implementation. For a complete test you can use traditional E2E tools.
loved this channel...you're awesome..!!
Just one request, Would it be possible for you to share your views and guidance on micro frontend with React + Redux + Redux Toolkit ?? Specifically managing the global state and inside the sub apps, plus how the communication works with subscriptions
Great idea. Thank you!
@@jherr thanks Jack, will look forward into this
Amazing video
bravo!
First came applets, then portlets, then widgets and now micro frontends. The concept has been the same but the architecture behind changed a lot for good.
I didn't get the diff between microfrontend and library. seems libraries/plugins just now have new name MICROFRONTEND 😁
Libraries are a build time dependency, micro-frontends are a runtime dependency.
How do we handle sharing libraries? What about one MFE running react 1.16.x and another with 1.16.y? Seems to me that the bundle would be huge, no?
I'm working on a project that would benefit from this approach given that we could do something about the bundle size. But I'm still not convinced that it's worth the complexity.
This, just like micro services them selves seems like it comes with a great cost in complexity.
Webpack 5's Module Federation shares the react and react-dom library (and whatever else you need) across the Micro-FEs. And it does a really good job with version arbitration and making you only load what's needed.
"I'm still not convinced that it's worth the complexity."
- that's very good actually! Use them only when you clearly see advantages outweigh disadvantages. Just as you compared MF to microservice architecture: microservices are significantly more difficult and, if you don't need them, stick to monoliths for simplicity. However, in some situations, monoliths reach a size after which the cost of scaling your teams or product is not acceptable.
When it comes to sharing libraries, apart from Jack's tip on sharing via Module Federation, there's also a rule for microservices (again) which goes: SHARE NOTHING. The thing is: if you have multiple teams that maintain various MFEs and you make them share a dependency, then - whenever you want to change that dependency in a breaking way (e.g. major version bump) - you have to do that in either all of the consumer-apps or none of them. And that's clearly breaking the goal of independent releases. So in ideal world, you'd prefer to share nothing in a distributed system.
You might, well, share lodash (only 1 dep in runtime, smaller bundle) if you don't expect it to introduce breaking changes anyhow soon, and reuse it. However, when a breaking lodash v5 arrives, you might want to make your apps use their own lodash versions (copies, bigger bundle) and then the seperate teams could migrate independently.
So in this case the tradeoff is: smaller bundle (shared deps) VS independent ops (shared nothing).
Common problematic situation in real-life microfrontends is: among many teams, there is a team which maintain internal company component library. It's specific to a certain framework (such as angular material, material UI, etc). The library shares, let's say, 50 components. Now, there are MFEs which use the components as they are right now (most recent versions). But within time, the component library would update their components, break the API at some point (e.g. major material UI being bumped, which breaks API) and some MFEs might decide NOT to update, because they have different business goals. But then, they need to use a component which is available only in the most recent version of the library... and there's a clash: either they update all their components (to enable the new one which they need) or none. You could think of publishing not a whole library, but each component separately - that would allow you to pick certain version of certain component from the lib, but. would introduce a significant overhead on the deployment process, bundle size and complexity.
Sharing is troublesome in distributed systems.
What exactly is the advantage compared to a component-library (with web component support) with deferred loading or hydration? I do not get it ^^
With Module Federation you get the ability to multiple projects to runtime depend on code that is pushed once and the projects get that code without re-deployment. With deferred loading you still have to redeploy to push updates.
@@jherr Ok thanks for the clarification ... with current CI/CD systems whenever a code push is happening, also an automatic deployment of the whole frontend can/may happen, and I prefer checking project compatibility at compile time in TypeScript before deployment as compared to just assume compatibility at runtime after deployment ... of course the individual deployment is kept as an advantage for MFEs ... but for me this single advantage is rather weak for the introduced complexity ...
I think you can see MFEs just as the microservices pattern ported to the frontend, right?
@@HannesBrantner It's totally fine that you want to use build-time linking and CI/CD. And you are welcome to your opinion on that as an MFE mechanism versus a runtime linking. And yes, I believe the current meta-definition of MFEs as the microservices patterns ported to the frontend. There are multiple ways to do that, even if you personally wouldn't choose some of the solutions.
To be honest, I still doubt the concept of MFE, because I see no established approach or live example, just an ad-hoc sites. How can the MFI manage authentication if each component have its own provider ? how to manage routing ? what if there is shared data between those MFI components ? How can we manage to make MFE components working together when we have fundamentally different approaches like Virtual DOM in React and a compiler for Svelte ?
I like micro frontend
I started developing websites in the early 90s and did it professionally for about 6 years, then took a 20 year break.... it is funny coming back and seeing that all the headaches have been fixed. I want to make an uphill, both ways, joke
It is kinda funny that Micro-FEs are fixing a problem that the bundlers created. We used to just import JS files all the time off the frontend. Or we would use something like requirejs to do dependency management.
Great video. I can't help but think that micro FE's could be really difficult to manage if you have multiple components that need to communicate with each other. It just sounds like a recipe for disaster to me. But maybe i'm wrong.
Ideally every MFE should be largely self-contained. Sharing the minimum amount of data (e.g. user ID and JWT).
How do MFEs compare with i-frames? It seems to be a similar concept of displaying a different application inside your host application.
IFrames can be MFEs. It's really just a matter of implementation.
MFEs implemented using IFrames are genuinely independent and walled off from the page. The JavaScript runs independently. The HTML and CSS are entirely independent. And you have to work pretty hard to tunnel data and messages between the host page and the . "Zoid" is the only IFrame based MFE system that I know of.
Other MFE systems, like SingleSPA, or Module Federation, have components that are integrated into the DOM of the host page. So they pick up the local CSS styling and also can be more easily integrated at the JavaScript level.
@@jherr ok that makes sense. At first it seemed like re-creating the wheel until you think about shared styles and data.
So if we were to use single-spa your suggestion is to not use any state management tool like redux
Single SPA parcels are meant to be self contained in their state. So the host app can use redux. And a parcel can use redux internally. But I doubt there is an elegant way to bridge them. I haven’t tried though.
Although you explained the difference between a library and a micro frontends I just don't really understand what you meant when you said micro frontends are different because they can be deployed independently. So can libraries can't they? I'm not sure what you meant. It's just not clear to me why you'd use a micro frontend over a library and how they really differ?
A library is built into an application. So if, for example, you have your shared header component in a library, and you have five apps, then all fives apps would need to be rebuilt and re-deployed for all a release of the header to be live across the entire site.
If your header is a micro-frontend then it's code that is consumed at runtime, instead of built into the compiled app. So, when the header is deployed it is live updated across all the sites immediately.
@@jherr ah so it can be lazy loaded in for example using imports?
@@zebcode Yep.
Perfect
Portlets from the yesteryears, but with content aggregation on the browser instead of within a servlet container. Would this be a fair statement ?
Sure. That would be a fair characterization.
How do you solve problem of loading same dependencies multiple times for such host page with many MFEs? Say your MFEs are in React, why would you want to force user to load mulitple React instances?
Are there any tools to help with that or os this still DIY space?
Module Federation solves that problem by having a Webpack runtime on the page that manages the shared dependencies. So if you've got a host page that has React, and an MFE that use React coming in, then when you ask webpack to load the MFE code it will first look to see if it can share any dependencies, (i.e. React) to avoid having the MFE load its own. That's actually not just an optimization, it's critical because there can only be one React and one React-DOM on the page at a time.
Ah right, Webpack 5 module federation. That assumes all teams must use it to bundle their mfe's using webpack 5, right? Or are other build tools able to "contribute" to client side modules registry Webpack runtime uses?
@@gustaff.weldon Yes to Webpack 5 for the time being. Though you can load WP5 federated modules into a Webpack 4 app. And other bundlers are starting to look at having a module standard that matches that. If you are looking for something entirely agnostic I'd look at Single SPA. But I think in that case, depending on how you use it (because it can use Module Federation as a code transport mechanism) you might be looking at having multiple sandboxed React instances.
Thanks. I think foregoing that bit of build tool choice freedom, to gain so much eg. on user front is not a big price to pay.
Single-spa was quite crude when I tested it last year, but one year is hell of a time in FE, so of course things have moved.
I'm grokking slowly through your MFE videos to bring myself up to date, so do not be surprised if I dig out some other videos with questions.
I'm trying to visualise what a possible MFE architecture for our ever growing SPA might be (and if it even makes sense).
I think you're doing a stellar work with those videos. They have that "meat" I like and learn from. Thanks
@@gustaff.weldon Ask as much as you like. At the end of the day most projects use a bundler. And that's either gonna be webpack, rollup or parcel in most cases. And way, way, way back Zack had module federation working with Rollup. So it is possible. The actual module federation client side contract itself is not all that complex.
Micro front ends and generic injectable components, check generic-forms in npmjs.
Thank you for the video please make a video on micro front end using services rendered framework like next.js
Can you tell me a little more about that? Do you want a Next.js site to consume Micro-FEs or to use Next.js to create a Micro-FEs?
Would like to see how the loading and unloading of micro apps works with server side rendering and how this impacts SEO .
@@sreekumarmenon Gotcha, well, in the meantime, you should check out OpenComponents th-cam.com/video/9CG0LeswOoM/w-d-xo.html and Edge Side Includes th-cam.com/video/4PoNBZl4t0Y/w-d-xo.html . OpenComponents has a server side rendering option, and Edge Side Includes would add the micro-fe HTML, JS, and CSS to the page before it gets to the customer. So both of those would have zero impact on SEO. Tailor (github.com/zalando/tailor) also does server side rendering. The other Micro-FE frameworks I've used (thus far) have been client side rendered.
I hope that helps.
I feel like this is a rehashing of the "Portal" architecture stuff from the mid 2000s.
We have.
I don't understand the scalibility part. Traditional package import/export can achieve exactly same thing
If you have ten different teams with different applications all of which deploy independently, which are then knitted together by a CDN provider (e.g. Akamai) then if you want to deploy a header update to all the sites simultaneously then each application would need to rebuild, pull the new package, etc. and deploy simultaneously, which is a challenge to say the least. In a Micro-FE approach all the applications are loosely coupled to the applications so they all get updated simultaneously.
Good point, thanks! I get it now. I only thought about a single website with multiple MFE components, not the multiple sites/pages maintained by different team scenario.
@@Somethingwronghere No problemo. That's just one scenario. The other is when you have a SAAS company that wants to provide hosted widgets for use on external uncontrolled pages. Back in the jQuery days we used to call these "widgets". Micro-FEs are a similar/same concept.
Con: styling can be an issue, not too terribly easy to create themes that are applicable across different MFE.
You could do an emotion theme if you could carry that context through to all the MFEs. Or you can do a common stylesheet. Or you could do a common stylesheet where the MFE injects any additional styling. There are ways, but yeah, it's not OOTB.
Is it possible to create micro frontend in diffrent framework and render it in one single page application with module federation if yes how to do that configuration
Please help
Ah, jeez. Everything old is new again. I was at a company building re-usable server side components in early 2000s for various industries, which would embed in their web pages. Now, just because we're moving *some* code to the front end we're suddenly using the "micro-frontend" buzzword. People were doing this crap with s since the year dot until that was disparaged.
Not just s, things like jQuery components as well. We lost the ability to do this when we went with bundlers. But, as it turns out, in some cases you need that runtime dependency support.
great videos
excellent
Hi sir, please tell any resources to learn micro frontends in react
Can you make video on
Exposing component which is connected to api and redux store ??
No, because I don't think you should do that.
Really helpful
Thank you!
@@jherr i just wanted to know how can I start project with pure javascript is there any reference which you can share with me, I dont want to use js framework need to use pure javascript with JQUERY
@@arjunmandloijquery is dead bro
It all sounds good but doesn't sound so much feasible and lot of overkill
It is overkill for small teams or small projects. Micro-FEs are more of a large company, large architecture thing. If you have multiple applications managed by multiple teams, and they need to share UI component at RUNTIME, then Micro-FEs are the way to go. If you don't need that runtime element then there is no need to pay for that complexity.
How does microfrontend differ from webcomponents?
Micro-frontends is an architecture, and web components is one, very good, implementation of that architecture.
Thank you!
Good job
what extension due use for the code snippets
GitHub Copilot.
How is this any different from a component ?
It is a component, but is integrated as a runtime dependency so that it can be deployed independently.
In addition it can be packaged in a way to make it usable across different view frameworks (e.g. React components on a Vue page, etc.) This is best accomplished using Single-SPA.
@@jherr Oh. I see
I see that you haven't touched micro frontends much after this time period(2-3 years ago), is it that they're not trendy anymore and monorepos are the new thing, or is it that there's nothing more to talk about them?
There is just a lot to talk about, and I released a new video on Module Federation today.
@@jherr awesome
No standards is a deal breaker
MFE in ELM, ever come across one ?
I've done ELM -> Custom Elements, so you could wrap that in an MFE.
@@jherr way of the future in my opinion.
Everything that the micro frontend approach brings to the table can be done via a monolith. That being said, vast majority of people structuring that monolith do it in the technical domain rather than the problem domain. Generally speaking they do not think about issues like extendibility, maintainability and parallel development. The basic architectural concept you are describing is decoupling, which is essential for highly resilient near endlessly extendable applications.
When it comes to multiple js packages, 2 x 5MB js files are significantly worse than a single 20MB js file (well .. technically not cz 2 files do download simultaneously, but). Latency is much more of a problem than download speeds. That is the case since the late 2000's.
There is nothing innovative or revolutionary about the modularity of a given project. The ideas behind it where known since the 60's. However, the industry as a whole takes React, Redux, mUI, scss, reducers, vue, the main menu, etc... as THE problem of a UI, not the actual problems which the app should solve. Hiring practices fully reflect this. The internal structures of companies fully reflect this. The hundreds of libraries tailored to help with the side effects of inadequate architectures reflect this perfectly.
You have all my thx trying to beat some sense into people but I think we are up against a dragon we cannot slay.
This is just offering options to tame the dragon. I think you are right, it will not be slayed.
A monolith? Not necessarily. If you have 100 developers on your project, so say 10 different teams working on different sub applications, I don’t think it makes sense to have to redeploy the entire monolith application just to fix a bug or add a feature for users. The issue with monoliths is because as a system gets larger, it’s very difficult to deploy changes; builds take longer, automated tests take longer, manually verifying an application takes longer, and there being a much higher risk someone from one team broke the app for everyone else.
@@WebDevCody If I am developing that app you can bet there wont be deploy issues or breaking errors for over 350 screens with heavy data processing. Not because I am such a brilliant programmer but ... lets say I have try-catch on some pure code (independent of volatile data, like server returns). I also make heavy use of pure html nodes which has little to no effect on deploy speed.
However, Its not just me, obviously. And the risk you are talking about is quite real, regardless of the size of the core (core: code which has afferent couplings across the entire app). One team under a joint pattern does not warrant micro frontends. Multiple, however, yes. You can't maintain discipline for multiple teams.
If you have 100 frontend developers on a project, I wont touch that with ten foot pole.
"Everything [...] can be done via a monolith."
No. Don't generalize, not _everything_.
Real-life example: Your company acquires other companies with systems built on top of completely different toolstacks (i.e. different frameworks), and those systems are really huge. And the dev teams are spread all over the world, each already maintaining one of the sub-apps. And your task is to "merge" them into a single system, and it makes a lot of sense from business perspective.
You won't rewrite them into a uniform toolstack (way too expensive). You can put them into a single repo, but this doesn't change anything, you NEED the teams to work separately on each sub-app. Welcome to micro-frontends.
can i get the sample
I'm starting this video sceptical I'll be honest
Micro frontend concept is created by architect, not developer. The architect try to educate developer how to implement a vision he has, but the he doesn't know how to do it. It is politics, chaos, mess. It is vietname war that you can't win.
Who is this "Marco Fernandes"?
One of Monny Lith's rebellious kids.
when it's another beautiful day for me I tend to leave outside, not staying in front of the PC, but...thanks anyway
Managing state across applications written with different frameworks/tools?
Sounds like fun 🤡🤡🤡
Hi, thank you for great video! I think you might be also interested in this... We just shipped initial version of the Isomorphic Layout Composer, complete solution for Micro Frontends composition into SPA with SSR support. github.com/namecheap/ilc
Fascinating!
microfronends
Wy this guy is always saying "micro fernand"? It's "micro front end" 🤣🤣🤣🤣🤣🤣🤣🤣
It's be'in frum Philly.
@@jherr it's ok. 😉
Thanks for the video
Fix your eye glasses . Not good for your eyes