Rehydrate client app with model data from server

[laurengarcia]

see discussion below

[clkao]

182 also attempt to do so but it seems to run into an issue in choo as app.start seems to be use fresh state

[laurengarcia]

For the near-term, (IMO) we should rehydrate the app by just serializing the server-side state into the server-rendered template to be picked up by client, example pattern here: https://github.com/erikras/react-redux-universal-hot-example/blob/master/src/helpers/Html.js#L52

The long-term solution should probably be not doing that^, but rather server-rendering the static bits of html for each hyperdrive, then aggressively cacheing the result as a CDN'd template, then making an xhr call to rehydrate the app (get numPeers, signalhubs, profile data).

The serialized short term solution saves us having to write an api for the xhr to call out to and spending time figuring out our cacheing strategy. I would guess that realistically this would be a week of work (or more), and if we want a full demo by Sept 1 I'm not willing to try to spend the time on it.

Am open to discussing any of this.

[laurengarcia]

(FWIW, I have never executed the kind of aggressive cacheing strategy that would allow a template with such dynamic contents as a hyperdrive's file list to be CDN'd and rendered+invalidated on changes but @yoshuawuyts was strongly advocating for the CDN approach and after thinking about it and discussing I agree that the CDN approach would be strong if we can get our cacheing strategy tuned just right for our purposes. The tuning process for our use is what will be time consuming IMO).

[okdistribute]

with webrtc, will the client-side javascript have to be rehydrating the app to update the number of peers?

[yoshuawuyts]

@laurengarcia after talking today I wrote down some thoughts about caching frontend apps (not specific to choo) here, perhaps it's useful https://github.com/yoshuawuyts/choo-handbook/pull/23

[juliangruber]

I wouldn't necessarily say that cached html + xhr for initial state is faster than non cached html including initial state because especially on bad internet round trip latency is a big factor too.

But also, let's not optimize prematurely here and just do the simplest thing that works for now.

[okdistribute]

+100 no premature optimizations

[laurengarcia]

@karissa: re: rehydration and numPeers, etc: been thinking about this alot and flipping back and forth. my current opinion is that numPeers should indeed come from webrtc (or the websocket-swarm thing that @juliangruber is working on). i'm currently of the opinion that the only rehydration data passed from server->client should be the data we used to server-render the page with; the server-render state data can be passed into the client app as the current state of the app and then choo+yo-yo can use it to do its dom-diffing thing as webrtc starts streaming data from the peers.

[laurengarcia]

@yoshuawuyts made a couple of wording suggestions in the choo-handbook PR you added. thanks!

[yoshuawuyts]

@laurengarcia thanks heaps! :grin:

[okdistribute]

yeah the websocket-swarm thing will be cool!