Move Flight Fixture to use Middleware instead of WebDevServer #26246
Conversation
This lets us put it in the same server that would be serving this content in a more real world scenario. I also de-CRA:ified this a bit by simplifying pieces we don't need.
facebook-github-bot
added
CLA Signed
React Core Team
|
Comparing: 212b89f...a05633d Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
No worries about "foo" being stateful? |
This lets us put it in the same server that would be serving this content in a more real world scenario. I also de-CRA:ified this a bit by simplifying pieces we don't need. I have more refactors coming for the SSR pieces but since many are eyeing these fixtures right now I figured I'd push earlier. The design here is that there are two servers: - Global - representing a "CDN" which will also include the SSR server. - Regional - representing something close to the data with low waterfall costs which include the RSC server. This is just an example. These are using the "unbundled" strategy for the RSC server just to show a simple case, but an implementation can use a bundled SSR server. A smart SSR bundler could also put RSC and SSR in the same server and even the same JS environment. It just need to ensure that the module graphs are kept separately - so that the `react-server` condition is respected. This include `react` itself. React will start breaking if this isn't respected because the runtime will get the wrong copy of `react`. Technically, you don't need the *entire* module graph to be separated. It just needs to be any part of the graph that depends on a fork. Like if "Client A" -> "foo" and "Server B" -> "foo", then it's ok for the module "foo" to be shared. However if "foo" -> "bar", and "bar" is forked by the "react-server" condition, then "foo" also needs to be duplicated in the module graph so that it can get two copies of "bar". DiffTrain build for [e7d7d4c](e7d7d4c)
You shouldn't really have a shared stateful dependency between Client and Server in this model. There's no "peerDependency" in this model. Outside the global coordinator that has to transfer the Server stream to the Client SSR. In this regard it's not really different from two node_modules being deduped or not deduped depending on versions of those dependencies. |
|
Thanks, @sebmarkbage. I'm one those who's eyeing these fixtures. 😊 Would love to see a version of the regional server that's bundled (for edge) instead of using the (experimental) node loader, maybe as a future iteration. |
|
@unstubbable You can take a look at Next.js for now. It's way more complicated, but some of that is inherent. There's a lot of complexity that goes into making that ecosystem compatible. For Node.js it's even more complicated because there's both bundled parts and unbundled parts of the graph with an ESM->CJS interop layer. Some of that is really out of the scope of React. There's also CSS which is another story. |
This lets us put it in the same server that would be serving this content in a more real world scenario.
I also de-CRA:ified this a bit by simplifying pieces we don't need.
I have more refactors coming for the SSR pieces but since many are eyeing these fixtures right now I figured I'd push earlier.
The design here is that there are two servers:
This is just an example.
These are using the "unbundled" strategy for the RSC server just to show a simple case, but an implementation can use a bundled SSR server.
A smart SSR bundler could also put RSC and SSR in the same server and even the same JS environment. It just need to ensure that the module graphs are kept separately - so that the
react-servercondition is respected. This includereactitself. React will start breaking if this isn't respected because the runtime will get the wrong copy ofreact. Technically, you don't need the entire module graph to be separated. It just needs to be any part of the graph that depends on a fork. Like if "Client A" -> "foo" and "Server B" -> "foo", then it's ok for the module "foo" to be shared. However if "foo" -> "bar", and "bar" is forked by the "react-server" condition, then "foo" also needs to be duplicated in the module graph so that it can get two copies of "bar".