SSR stuck after remote rebuilds #5

Activity

1. telenko commented on Aug 7, 2021

   

   telenko

   on Aug 7, 2021

   Owner

   More actions

   Hi @Kinbaum , thanks for raising the issue. I'll take a look, didn't test my solution with that conditions.
   Thanks.
2. telenko commented on Aug 22, 2021

   

   telenko

   on Aug 22, 2021

   Owner

   More actions

   Hi @Kinbaum, unfortunately I cann't reproduce the issue with node-mf-example. Can you bring more details on your projects setup? What is the http status you receive when fetch the nextjs page?
3. Kinbaum commented on Aug 22, 2021

   

   Kinbaum

   on Aug 22, 2021

   Last edited by Kinbaum

   Author

   More actions

   Hey, I have created a reproduction scenario using node-mf-example

   Initial build

   1. Run yarn build && yarn start in both host and remoteLib
   2. You will see everything working as expected

   Modifying the remote

   Do not touch or modify the host. This should be left running.

   1. Now in remoteLib kill the application and change the button text
   2. Run yarn build && yarn start again to build the remote

   

   Observing changes in the host (use incognito mode in Chrome)

   1. Go back to the host application.
   2. On the client side we should see Some new button
   3. However, on the server side, we will still see Hey, I'm a smart button as SSR is stuck and does not update between remote builds.

   

   Right-click and select View page source to see the SSR'd version of the page.

   
4. wibed commented on Aug 27, 2021

   

   wibed

   on Aug 27, 2021

   More actions

   bump
5. ScriptedAlchemy commented on Feb 7, 2022

   

   ScriptedAlchemy

   on Feb 7, 2022

   More actions

   This is a very complex problem to try and solve. Hot reloading servers is tricky since webpack already required the chunk from another build, it wont redownload a chunk it already has.

   There are ways around this though.

   1. you can use federation on a custom express server to import the next() route handler. This would allow you to purge require cache, flush express route stack, and re-instantiate webpack in a empty closure, thus requiring webpack to re-stream chunks from other remotes
   2. Use a worker thread. Run the next middleware inside a worker so you can dispose of that thread and start another worker which cleans the "stuck" module problem in a similar way a process restart would
   3. have a reload endpoint that kills the process and then passes the argv back to a spawn command

   Some of these patterns might be best used on a stale while revalidate loop or timer so that the current page load is not slowed down by needing to restream modules
6. noreiller commented on Feb 7, 2022

   

   noreiller

   on Feb 7, 2022

   Contributor

   More actions

   My solution was an endpoint on my app that receives other remote apps updates so I can flush require cache.
   As I use the promise remote with node-mf, the app stream the new remote app uri and avoid to get stuck.
7. ScriptedAlchemy commented on Feb 18, 2022

   

   ScriptedAlchemy

   on Feb 18, 2022

   More actions

   Okay so I’ve close to releasing a large update to my groups internal stream plugin.

   I’m using something that calculates the collective hash of the remotes. During invocations, I’ll load remotes again in the background and calculate the hash. If it mismatches the current hash, I set a marker that waits for server to close current requests and performs a hot reload.

   I’m looking at using vm.script, shared array buffer, and v8 isolates as a way to protect the main thread from pollution.

   Has anyone else noticed nested remote modules being skipped on first invocations?