I have tried with angular 9 and with multi repo approach as our team has different teams have their won deliverables. Tried to set it up with custom webpack without cli as my organisation didn’t support yarn.will be really helpful if you could give me an advise. For now we put on hold as we are having issues with scss file sharing
Great Sharing..!!! please advice, I have a question, if we create it on angular 13. i got this error on CarouselHostComponent ==> error TS2322: Type 'ComponentRef' is not assignable to type 'ComponentRef' any issue with angular 13 ??
Sounds like just a basic TypeScript issue. You are trying to set something of type `ComponentRef` to `ComponentRef`, so you probably need to cast that.
Hey ... thank you for the video this works completely fine in local , but as soon as i push host and remote on cloud platform, it is giving CORS error while calling the remote application .Can you pease help to resolve this issue , both application is bootstrapped using ng serve .
I am looking to share services and make them as singletons to be used between my shell and micro front ends in angular. I have multi repo MFEs so NX share libraries would not be a good option.
Greetings Jack. Assume all the logic (api call etc) in the PokemonCarouselComponent was refactored into a PokemonCarouselService so that the component had a dependency on the service. how would this be exposed such that hosts would consume the remote component only (and it would transitively import the service dependency). is this even the correct approach?
@@jherr Yes that covers some part, thank you. I would be curious how larger companies would tacke module federation. Generally these companies have multiple teams working on multiple projects and a centralized team creating components the main flair of module federation is gone (where allowing to import between projects is possible). If a core team worked on components for the projects you end up with federated modules being centralized into a one project. Thus being close to having a repository like for web components, open components, parcels, pilets, etc. But I guess this isn't the purpose of the federated modules. Regardless of centralization or not, federated modules would have a contract for each version being used, that is fine. And where you'd fetch the federated modules would also be versioned. So I'm not sure what other advantages federated modules brings to companies having this type of organization. Also many thank you for your contributions to the MFE world, you breaking things down to their essence is crazy good where these new technologies are constantly growing.
@@Ghruuul Thanks for the thoughtful reply. You have to work to make federated modules versioned. The big win of establishing these "runtime dependencies" using something like federated modules, or anything else, is that you can update parts of the application without re-building and re-deploying the host application. A good example is a header/footer where you have multiple applications that include the header/footer and you want them all to show the new header/footer as soon as its updated. With a build time dependency you'd have to build them all and then roll them all out at the same time. With a runtime dependency, you update the runtime dependency and you're done. Of course, there is an associated risk there.
@@jherr Thank you. Maybe the big challenge is how to "force" a newer version of a federated module respect the contract that has been implemented. The advantage is clear, loading modules runtime from another application without needing to publish the parts somewhere is definitely awesome.
@@Ghruuul So what I propose is to have a shared NPM module with the TypeScript types that the host expects and that the remote module must follow. And that NPM module is consumed at build time by both. So then later as new optional fields are updated they are first supported in the host and then accepted in the remote module, and that will give you a safe upgrade path. If it's followed. There is no runtime guarantee.
I've been experimenting with Angular 13, the documentation says to use `viewContainerRef.createComponent` for dynamic components, but the API itself says that method is deprecated and there is a different way to do it in 13. I'm confused.
@@rzzo Well, good news then, I've got that working. I'm just concerned that now I'm not doing it the "Angular way" (which is like the "Chicago way" but with less guns.) j/k Anyway, jump on the Discord server and hit me up in the Angular channel. I can shoot you over my working code you can see if it's ok or if I need to talk with Manfred to figure out what the "Angular way" is.
@@jherr Hahaha! I think I will be using that "Chicago Way" from here on out! I joined the Angular community and Angular discord channels but I am not seeing your name, do you go by something else on there?
Thank you Jack. I am trying to setup my own module federation using React / Nx. Would love to see your setup. Beside that, integrate with single-spa to handle the rendering/routing to different pages?
@@jherr Let's say if I have multiple mfe apps which each app has its own router. Currently, I have my own customization to handle the routing on my container app and control when to show/not show it. Also, create a mount function for the container to attach it to the DOM. In single-spa, it seems it has features on handling routing/ui rendering and the app lifecycle. However, I haven't got a chance to try single-spa yet. So please correct me if I am wrong.
@@JasonRAN0 I'm sure Angular has some excellent router options that you can use. The big advantage of Single SPA is that it allows for you to mix in micro-FEs from different tech stacks. But if you aren't going to be doing that you don't need to add the overhead of wrapping your Angular components as Single SPA parcels and then only to unwrap them back into an Angular host app.
yea can you do this with nextjs and react + tailwind that would be really helpful. Maybe dive deeper into the benefits of micro front ends? Thanks again! love your content
Hello Jack, very good contribution, but I wanted to ask you if it is possible to share components as a utility module so that other components reuse the selectors of the shared component is it possible in angular?
@@jherr I see, so sass/scss mixins are a no-go? I have a particular problem - my remote project needs to be themed according to my host project's color palette. If there was a way I could pull in the mixins with the color styles from my remote project and pass my palette from the host into those mixins, that would be perfect
@@vineetkaushik5044 Module Federation can't directly handle CSS files. To share CSS it needs to be implemented using some type of CSS in JS, because only JavaScript code can be federated.
Probably yeah. It's not actually overhead because it just means splitting out those components into a different bundle. Which doesn't mean replication. It just means your app will be code split additionally along the MFE sharing lines as well as any other code splitting you are doing.
@@jherr thanks for your answer! so if i understood correctly, it makes sense, only if you have an existing application and you're exporting one/some components as MFE. But it doesn't make sense to create, let say UI library as MFEs because it will require some servers to serve the apps. Or you can build them and serve as a static content?
@@oleksandrsanzharevskyy No. I know that I demonstrate MFEs on running servers, but you don't need servers to deploy MFEs. Federated Modules are just static JavaScript files that SHOULD be deployed on static asset stores or CDNs.
Sharing microfrontend within the same monorepo isn't a big deal. Next step would be to share components and states between microfrontends that are not in same repo
Why do I have to import all the same app.modules.ts imports from the search app into the home app app.modules.ts? Why doesn't module federation have the remote app bring things over encapsulated? That feels like it's tightly coupled :(
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
That was awesome! Please more content on angular would be great!!!! 🤩
Love the content and your introductions out on the wilderness!
A great channel and a great, calm engineer. Thanks!
Waiting eagerly for react micro FE speed run
I second it. with singlespa
Awesome tutorial..Thanks a lot for sharing this with the community
Can't wait for the React / NX version. 👍
Great video Jack. 👌🏻
Crisp & Clear
Really great content. Thank you!
i want to use react for the container application and angular components on that react container? can you do a video on that?
I have tried with angular 9 and with multi repo approach as our team has different teams have their won deliverables. Tried to set it up with custom webpack without cli as my organisation didn’t support yarn.will be really helpful if you could give me an advise. For now we put on hold as we are having issues with scss file sharing
Great ,as always Jack
If that component depends on some external 3rd part module then how would I be able to expose it and how to use it in the host container?
What is the command in your video at 5:31?
Great Sharing..!!!
please advice, I have a question, if we create it on angular 13. i got this error on CarouselHostComponent ==>
error TS2322: Type 'ComponentRef' is not assignable to type 'ComponentRef'
any issue with angular 13 ??
Sounds like just a basic TypeScript issue. You are trying to set something of type `ComponentRef` to `ComponentRef`, so you probably need to cast that.
This is angular 13 issue. ComponentFactoryResolver is deprecated in Angular 13
@@bhagwaticharanmishra2962 I got errors after I try this in Angular 13: import {
Component,
OnInit,
//ComponentFactoryResolver,
ViewContainerRef,
ComponentRef,
} from '@angular/core';
import { loadRemoteModule } from '@angular-architects/module-federation';
@Component({
selector: 'ang-pokemon-mfe-carousel-host',
templateUrl: './carousel-host.component.html',
styleUrls: ['./carousel-host.component.scss'],
})
export class CarouselHostComponent implements OnInit {
constructor(
//private cfr: ComponentFactoryResolver,
private vcref: ViewContainerRef
) {}
async ngOnInit() {
const { PokemonCarouselComponent } = await loadRemoteModule({
remoteEntry: 'localhost:4201/remoteEntry.js',
remoteName: 'search',
exposedModule: './CarouselComponent',
});
const componentRef: ComponentRef = this.vcref.createComponent(
//this.cfr.resolveComponentFactory(PokemonCarouselComponent)
PokemonCarouselComponent
);
componentRef.instance.search = 'p';
}
}
@@davle123456789 this is because component ref related stuffs are deprecated in angular 13
Thanks Jack 😊
What is the sidebar extension you're using that's right above Nx Console, as well as the one that's right above Live Share?
Hey ... thank you for the video this works completely fine in local , but as soon as i push host and remote on cloud platform, it is giving CORS error while calling the remote application .Can you pease help to resolve this issue , both application is bootstrapped using ng serve .
I am looking to share services and make them as singletons to be used between my shell and micro front ends in angular.
I have multi repo MFEs so NX share libraries would not be a good option.
Greetings Jack. Assume all the logic (api call etc) in the PokemonCarouselComponent was refactored into a PokemonCarouselService so that the component had a dependency on the service. how would this be exposed such that hosts would consume the remote component only (and it would transitively import the service dependency). is this even the correct approach?
I would be interested what the strategy is to use MicroFEs and Module Federation in production. There are missing pieces at the moment.
Does this help? ruclips.net/video/MU8_LP8R_ZI/видео.html
@@jherr Yes that covers some part, thank you.
I would be curious how larger companies would tacke module federation. Generally these companies have multiple teams working on multiple projects and a centralized team creating components the main flair of module federation is gone (where allowing to import between projects is possible).
If a core team worked on components for the projects you end up with federated modules being centralized into a one project. Thus being close to having a repository like for web components, open components, parcels, pilets, etc. But I guess this isn't the purpose of the federated modules.
Regardless of centralization or not, federated modules would have a contract for each version being used, that is fine. And where you'd fetch the federated modules would also be versioned.
So I'm not sure what other advantages federated modules brings to companies having this type of organization.
Also many thank you for your contributions to the MFE world, you breaking things down to their essence is crazy good where these new technologies are constantly growing.
@@Ghruuul Thanks for the thoughtful reply. You have to work to make federated modules versioned. The big win of establishing these "runtime dependencies" using something like federated modules, or anything else, is that you can update parts of the application without re-building and re-deploying the host application. A good example is a header/footer where you have multiple applications that include the header/footer and you want them all to show the new header/footer as soon as its updated. With a build time dependency you'd have to build them all and then roll them all out at the same time. With a runtime dependency, you update the runtime dependency and you're done. Of course, there is an associated risk there.
@@jherr Thank you. Maybe the big challenge is how to "force" a newer version of a federated module respect the contract that has been implemented. The advantage is clear, loading modules runtime from another application without needing to publish the parts somewhere is definitely awesome.
@@Ghruuul So what I propose is to have a shared NPM module with the TypeScript types that the host expects and that the remote module must follow. And that NPM module is consumed at build time by both. So then later as new optional fields are updated they are first supported in the host and then accepted in the remote module, and that will give you a safe upgrade path. If it's followed. There is no runtime guarantee.
Awesome video! Wondering if you can post an update on this using Angular 13? I tried to convert this but cannot get the new Dynamic Component to load
I've been experimenting with Angular 13, the documentation says to use `viewContainerRef.createComponent` for dynamic components, but the API itself says that method is deprecated and there is a different way to do it in 13. I'm confused.
@@jherr That’s exactly what I was running into and have not been able to get it to actually load the carousel dynamically
@@rzzo Well, good news then, I've got that working. I'm just concerned that now I'm not doing it the "Angular way" (which is like the "Chicago way" but with less guns.) j/k Anyway, jump on the Discord server and hit me up in the Angular channel. I can shoot you over my working code you can see if it's ok or if I need to talk with Manfred to figure out what the "Angular way" is.
@@jherr Hahaha! I think I will be using that "Chicago Way" from here on out! I joined the Angular community and Angular discord channels but I am not seeing your name, do you go by something else on there?
@@rzzo Ah, I meant my server: discord.gg/HkvRaQCN
Great!! Thank you Jack. Can this module federations be applied to react native components as well? If so, can you please do a video on that. Thank you
Thank you Jack. I am trying to setup my own module federation using React / Nx. Would love to see your setup. Beside that, integrate with single-spa to handle the rendering/routing to different pages?
Cool. But can you let me know what Single SPA is doing in this scenario?
@@jherr Let's say if I have multiple mfe apps which each app has its own router. Currently, I have my own customization to handle the routing on my container app and control when to show/not show it. Also, create a mount function for the container to attach it to the DOM.
In single-spa, it seems it has features on handling routing/ui rendering and the app lifecycle. However, I haven't got a chance to try single-spa yet. So please correct me if I am wrong.
@@JasonRAN0 I'm sure Angular has some excellent router options that you can use. The big advantage of Single SPA is that it allows for you to mix in micro-FEs from different tech stacks. But if you aren't going to be doing that you don't need to add the overhead of wrapping your Angular components as Single SPA parcels and then only to unwrap them back into an Angular host app.
Waiting your tutorial for Next.js with Module Federation :-)
yea can you do this with nextjs and react + tailwind that would be really helpful. Maybe dive deeper into the benefits of micro front ends? Thanks again! love your content
Hello Jack, very good contribution, but I wanted to ask you if it is possible to share components as a utility module so that other components reuse the selectors of the shared component is it possible in angular?
Anyway we can expose mixins for consumption by the host from a remote application?
If it's an executable piece of JavaScript code it can be exposed.
@@jherr I see, so sass/scss mixins are a no-go? I have a particular problem - my remote project needs to be themed according to my host project's color palette. If there was a way I could pull in the mixins with the color styles from my remote project and pass my palette from the host into those mixins, that would be perfect
@@vineetkaushik5044 Module Federation can't directly handle CSS files. To share CSS it needs to be implemented using some type of CSS in JS, because only JavaScript code can be federated.
Maybe my question is stupid, but it will work with angular cli instead of nx ?
It should, yes.
Thank u so much
does it mean, if you have N components, and you wanna to use them as MFE, you need to serve all of N components?
Probably yeah. It's not actually overhead because it just means splitting out those components into a different bundle. Which doesn't mean replication. It just means your app will be code split additionally along the MFE sharing lines as well as any other code splitting you are doing.
@@jherr thanks for your answer! so if i understood correctly, it makes sense, only if you have an existing application and you're exporting one/some components as MFE. But it doesn't make sense to create, let say UI library as MFEs because it will require some servers to serve the apps. Or you can build them and serve as a static content?
@@oleksandrsanzharevskyy No. I know that I demonstrate MFEs on running servers, but you don't need servers to deploy MFEs. Federated Modules are just static JavaScript files that SHOULD be deployed on static asset stores or CDNs.
@@jherr that's make sense. Thank you for your answer and great tutorials!
Nice! :-)
Sharing microfrontend within the same monorepo isn't a big deal.
Next step would be to share components and states between microfrontends that are not in same repo
it could be more informative if you could have explain contents of webpack line by line , you just jumped on plugin section
Why do I have to import all the same app.modules.ts imports from the search app into the home app app.modules.ts? Why doesn't module federation have the remote app bring things over encapsulated? That feels like it's tightly coupled :(