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

[benjoz]

Step to reproduce

In a first terminal - Terminal 1

• cd server-side-rendering/website1
• yarn install
• yarn build && yarn serve

In a second terminal - Terminal 2

• cd server-side-rendering/website2
• yarn install
• yarn build && yarn serve

at this step : everything is working fine and header component is loaded through localhost:3002

Now try to update header component (website2) without touching host (website1)

Terminal 2

• CTRL+C
• on website2/src/components/SomeComponent.js update line 13 with "Zack is awesome"
• yarn build && yarn serve

Actual results
on localhost:3001 - Client side you will see "Zack is awesome"
however on the DOM you will still see "Header"

Result expected
we should have "Zack is awesome" on Client & DOM without having to rebuild HOST(website1)

[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.

[7rulnik]

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

[benjoz]

Done @7rulnik :)

[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.

[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]

@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]

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

[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