ezekielchentnik / preact-pwa

Super fast progressive web app with small footprint & minimal dependancies
https://preact-pwa-yfxiijbzit.now.sh/
MIT License
511 stars 45 forks source link

Isomorphic rendering #2

Closed ricardobeat closed 7 years ago

ricardobeat commented 7 years ago

Hi Zeek! Just kidding :)

I'm not seeing the isomorphic rendering in action - when I visit https://preact-pwa.appspot.com/articles for example the article list markup is not being served in the body. Does it have to be enabled somewhere?

cheers!

ezekielchentnik commented 7 years ago

@ricardobeat Yo! boo!

if you peek in the root route: https://github.com/ezekielchentnik/preact-pwa/blob/master/src/server/routes/root.js#L54 you can adjust the withTimeout threshold to yield SSR - depending on the speed of your API.

The idea is to allow an 'escape hatch' for abnormal or slow API requests. If any server side API calls are slow, they will be aborted (raced against the threshold) so that we do not make the client wait 'too long' and can allow the client to take over. In the cases that the API response is fast, you get the advantage of SSR.

This logic can be improved. Likely if the server request is slow, by the time the client makes the request, it too will be slow. maybe.

This can also be used to warm your API cache so by the time the client hits it, it gets a cached response.

Also, there is a case with service workers that needs to be fixed: when SSR does work the page will be cached by the service worker - The client needs to be smarter and invalidate the cached data inside redux and refetch (based on whatever threshold make sense). This would ensure a nice SSR but then still allow the client to update and be fresh. Right now it works because that demo api call returns a static set of data.

Finally, the server logic could be smarter and cancel the original API requests if the 'escape hatch' is used and bypassed to client. this will reduce redundant requests to your API.

Any ideas or help in this regard would be awesome! Cheers.