Extremely low performance on production build

[thanh-nguyen-codeleap]

With what library do you have an issue?

native-federation

Reproduction of the bug/regression with instructions

After converting SPA to Native Federation, the app initial time increase to DOUBLE
SPA

Native Federation

I took a closer look and it seems the Native federation eager loaded every libraries, both local and published libraries.

Current setup for federation apps:
`const {
withNativeFederation,
shareAll,
} = require('@angular-architects/native-federation/config');

module.exports = withNativeFederation({
name: 'sales',

shared: {
...shareAll({
singleton: true,
strictVersion: true,
requiredVersion: 'auto',
}),
},

skip: [
'rxjs/ajax',
'rxjs/fetch',
'rxjs/testing',
'rxjs/webSocket',
'ts-jest',
],

features: {},
});
`

Expected behavior

The app loading speed is the same as SPA

Versions of Native/Module Federation, Angular, Node, Browser, and operating system

Federation: 20.1.6
Angular: 20.3.2

Other information

No response

I would be willing to submit a PR to fix this issue

• Yes
• No

[Aukevanoost]

Hi @thanh-nguyen-codeleap

I'm sorry to hear that. The native-federation runtime shouldn't download dependencies eagerly. Only when an import occurs, this is how the importmap spec works.

It is hard to reproduce your setup however, one thing to keep in mind with sharing dependencies is that treeshaking is not possible anymore due to the bundler (esbuild in this case) not knowing which remotes use what parts of the dependencies. Therefore, if all remotes use different versions of the externals (dependencies), the app will indeed be bigger in size in a mfe setup, rather than in a SPA where all externals are treeshaked and bundled into the final build.

The real benefit starts to occur when multiple micro frontends use the same externals, then the benefit of the external being reused will outweigh the extra size that comes with the lack of treeshaking.

Does this make sense?

[thanh-nguyen-codeleap]

So in short sharing libraries will not and can never be treeshaked, which means if a code import an index file from a local libraries, it will download everything exported in that index file, recursively. And the initial loading time will always be way slower than a single SPA app?

[Aukevanoost]

Technically yes, because nf cant just remove code since it doesnt know what the other remotes are using.

But on the bright side, if 3 remotes use that same library, it only needs to be downloaded once and used thrice. On a regular website, if you merged 3 spa's into one application, you'd have to bundle the same library in all 3 applications.
So there's the real tradeoff. Micro frontends start to shine the more remotes you have.

[thanh-nguyen-codeleap]

But I'm talking about the app initial, which even if if 3 remote are compressed in on single SPA, it still won't be a problem. Moreover, creating more remote apps just makes it harder to share the pages between them. It's like you're introducing new problems just to pat yourself on the back for fixing half of them. Now I'm really questioning how this will scale up if the shared libraries keep growing bigger and bigger, which will always be the case in the projects I'm working on. The concept itself is too unsustainable for enterprise projects

[manfredsteyer]

Did you already try with the new removeUnusedDeps feature?

[Aukevanoost]

Hi @thanh-nguyen-codeleap

What do you mean with this sentence?

But I'm talking about the app initial, which even if if 3 remote are compressed in on single SPA, it still won't be a problem. Moreover, creating more remote apps just makes it harder to share the pages between them.

The answer is actually pretty simple, per shared external (read dependency), you have to choose if you want to share it or not. Sharing the dependency means adding it to the "shared" property in your federation.config.js. When a library is shared, you can obviously not treeshake the bundle as i mentioned before, but the tradeoff is that it is now built to be reused by multiple micro frontends. A shared external is added to the importmap, and only downloaded when an import occurs in one of the remotes that needs the external. Therefore, this feature is great for libraries that are used by multiple remotes (read micro frontends), or if the remotes use a big chunk of the library, like Angular core (so less dead code removal required). As far as I know, externals are not preloaded.

Now, if you only use a small portion of the external, (like only 1 function or class). It might make sense to not share the dependency by adding it to the skip array or removing it from the shared array. When this happens, the angular builder will treat this dependency as part of the app and will treeshake (and optimize) the code in the remote's (again, read micro frontend) bundle. Note that this means that the external cannot be shared with other remotes anymore.

Finally, I'd like to point out that I understand your frustration, however there will (currently with all mfe solutions) always be a small performance penalty for micro frontend orchestration. Native federation only tries to minimize this with the abovementioned features.

Hope this clarifies the tradeoff a bit.

[Aukevanoost]

The problem is most of the things I want to share are shared components and directive. Without tree shaking, it took 2 seconds to initialize a single library but if you don't share and the host app uses the same component as the remote, then you'll face the component collision warnings and the lost the entire context from the host app, such as the injection.

Right, that makes sense. From what I hear I am assuming that you have a big shared components library. What you can do (and what we did) is help Angular a bit by breaking up your shared library into multiple libraries. This way, if you break it up well, the host only downloads the sublibrary that contains all the components that it need. The ng-packagr library contains a nice feature for this: Check out this article.

Finally, we'll be sure to add this tradeoff to the docs. I haven't seen your setup but I generally recommend as little shared state and context between the host and remotes as possible. This creates unwanted coupling.

[thanh-nguyen-codeleap]

The problem is most of the things I want to share are shared components and directive. Without tree shaking, it took 2 seconds to initialize a single library but if you don't share and the host app uses the same component as the remote, then you'll face the component collision warnings and the lost the entire context from the host app, such as the injection.

Right, that makes sense. From what I hear I am assuming that you have a big shared components library. What you can do (and what we did) is help Angular a bit by breaking up your shared library into multiple libraries. This way, if you break it up well, the host only downloads the sublibrary that contains all the components that it need. The ng-packagr library contains a nice feature for this: Check out this article.

Finally, we'll be sure to add this tradeoff to the docs. I haven't seen your setup but I generally recommend as little shared state and context between the host and remotes as possible. This creates unwanted coupling.

Correct me if I'm wrong but without skipping the newly created entry points, they will still be eagerly loaded? Anyway, here's some added context: I have 4 apps:
Host: core
Remote: sales, dispo, login
Libraries: shared, nf-shared

The problem arises when the login doesn't need most of the shared components, but the dispo and sales do. So the login is burdened with a huge of unused code and run extremely slow. The only way to solve this is to make another login SPA and deploy it to a separate domain, but it also means after logging in, the entire app will need to be initialized again.

[Aukevanoost]

Correct me if I'm wrong but without skipping the newly created entry points, they will still be eagerly loaded?

Technically yes and no, so the concept of eager or lazy loading is totally up to you. As stated before, if you create a shared library (like @angular/core), it will be added to the import map like so:

{ "imports": {
  "@angular/core":"http://my.mfe1.org/angular_core.js"
}}

Now whenever the browser comes across an import "@angular/core". It will download and resolve the import. Not before.

So what could happen is that you run loadRemoteModule eagerly, resulting in all code being executed before you actually need it. Now as you already know, if you have one big shared library, because nf (or mf or anything) cannot treeshake that library (since it doesnt know what to remove). If you break up the library into "parts the login uses" and "parts the sales uses" and "parts the dispo uses", then by my abovementioned theory, only the "login part" of the shared library should be downloaded and used on the login page.

This does however take into account that you use lazy loading for your routing like so:

export const routes: Routes = [
  {
    path: '/sales',
    loadComponent: () =>
      loadRemoteModule('sales', './Component').then((m) => m.AppComponent),
  },
];

And this also takes into account that you don't import the code from all modules of your shared library in your host, since then (obviously) everything needs to be downloaded anyway.

So in summary, initFederation creates the import map but doesnt download the resources, loadRemoteModule downloads the imports of the remote, triggering the code execution.

Hope this helps :)

[thanh-nguyen-codeleap]

Correct me if I'm wrong but without skipping the newly created entry points, they will still be eagerly loaded?

Technically yes and no, so the concept of eager or lazy loading is totally up to you. As stated before, if you create a shared library (like @angular/core), it will be added to the import map like so:

{ "imports": {
"@angular/core":"http://my.mfe1.org/angular_core.js"
}}
Now whenever the browser comes across an import "@angular/core". It will download and resolve the import. Not before.

So what could happen is that you run loadRemoteModule eagerly, resulting in all code being executed before you actually need it. Now as you already know, if you have one big shared library, because nf (or mf or anything) cannot treeshake that library (since it doesnt know what to remove). If you break up the library into "parts the login uses" and "parts the sales uses" and "parts the dispo uses", then by my abovementioned theory, only the "login part" of the shared library should be downloaded and used on the login page.

This does however take into account that you use lazy loading for your routing like so:

export const routes: Routes = [
{
path: '/sales',
loadComponent: () =>
loadRemoteModule('sales', './Component').then((m) => m.AppComponent),
},
];
And this also takes into account that you don't import the code from all modules of your shared library in your host, since then (obviously) everything needs to be downloaded anyway.

So in summary, initFederation creates the import map but doesnt download the resources, loadRemoteModule downloads the imports of the remote, triggering the code execution.

Hope this helps :)

So correct me if I'm wrong but if a published library doesn't have sub entry points and it context needs to be shared across the remote apps, such as @microsoft/applicationinsights-web, then there's nothing we can do about it without asking the owner to create sub entry points?

[Aukevanoost]

Well, yes. But for these packages you can also choose to add them to the skip array. Then they will be packaged in your final build instead of treated as external.

That might mean that the code will be duplicated if you use it in multiple remotes, but if that is still less code than the not-treeshaked external, then that's the tradeoff you're making.