[server-side-rendering] - server doesn't re-fetch modules

[module-federation]

[server-side-rendering] - server doesn't re-fetch modules

[7rulnik]

BTW, the whole solution with the same disk looks weird. I believe that people mostly use docker containers. So we need the way to load remote chunks by HTTP on the server-side

[ScriptedAlchemy]

changes are, the next rewrite on streamed systems will resolve this. We are actively rewriting it.
I'm also working with Google, so we plan to introduce programmatic memory management into V8.

If anyone wants to collaborate on this, I'm willing to talk about it in more depth. But for the time being, i have alternative solutions that are part of proprietary tools. They take a very different approach but this is possible to achieve imo

[7rulnik]

@benjoz could you rename it to something like that server doesn't re-fetch modules?

[benjoz]

Done @7rulnik :)

[7rulnik]

Yep, currently it's just proof of concept how we could connect 2 bundles. We don't have dynamic load of remoteEntry in website1.

[theKashey]

Just wondering - is it "doesn't refetch", or "still use cached one"

[7rulnik]

As I can remember it loads module only once, stores it in the cache, and doesn't re-fetch it.
But some new features for loading remotes were introduced in beta-17, but I didn't have time to check it. Maybe it will help.

[ScriptedAlchemy]

I appear to have fixed this issue in streamed servers, however on local disks its not working. this is pretty much the need for HMR in production servers. Which is what was built into streamed tech.
@theKashey do you think your node cache clearing would work within this repo (server-side-rendering example) Since I'm not injecting phantom files during streams :P

[ScriptedAlchemy]

pretty much either the webpack cache or node cache needs to be cleared i guess for the demo purpose. Wipe all caches upon each invocation

[ScriptedAlchemy]

I also use target: async-node. Which might work better for SSR?

[theKashey]

async-node is not supported by every "import->require" rewiring code splitting solution, which is every codesplitting library, universal included, except imported-components, which will basically eagerly import everything, making async mode a bit useless.

---

And yes - cache clearing is a must for any platform.

[ScriptedAlchemy]

@7rulnik you want this sucker. https://youtu.be/kOuoSBTCzl4

[ScriptedAlchemy]

what we could do on SSR is have the name of remoteEntry change in a random way so it would "hot reload" or redownload code

[theKashey]

please just use uuid

[theKashey]

@7rulnik you want this sucker. https://youtu.be/kOuoSBTCzl4

21:00 sounds like solution for "synchronous" i18n file loading, ie without waterfall of those "headers and footers", and load the loader first.

[7rulnik]

@ScriptedAlchemy yep but it will lead to a memory leak

[ScriptedAlchemy]

Just need hands willing to progress the research

[theKashey]

Talk about programatic memory management? I am in :)

[ScriptedAlchemy]

@theKashey I have a simpler SSR demo in pull request. Maybe we could work off that and try to come with a solution?

[theKashey]

@ScriptedAlchemy - in which one?

[ScriptedAlchemy]

I've got some ideas on this. With startup code a available we should be able to pass chunks back to the host.

For servers getting stuck. I've got a theory on how to solve this but short on time to build it out.

[ScriptedAlchemy]

You can restart the process or make the host use it’s own remote as the real entry point. Then you can send a update command that pretty much re requires the remote and in the process purges module cache because we “restart” webpack runtime