Sign in to join this conversation, and others like it, in the communities you care about.
React / General
My experience has been that streaming works well when styles have been extracted as part of the build process.
But for CSS-in-JS you need to get the full response to send the styles first, otherwise there's a FOUC.
And no, client-side-only rendering is not enough to get indexed on search engines haha
Before you even import any
Just playing devil‘s advocate here, because as shown in the article, SSR brings a lot of complexity compared to a static site. So I’m trying to understand exactly what unique value you get from it.
I haven't yet understood how the cache gets invalidated when a page's contents changes. It looks like the cache key is only `request.path`, however this doesn't change when the page contents change?
Working on that though, planning to have proper invalidation sometime soon
Any ideas on how to key things so they can easily be invalidated when anything changes? Imagine a thread page like this one
The issue is that a thread page like this one needs to be invalidated if:
1. A new message is sent
2. The contents are edited
3. Any participant changes their name or username or avatar
4. The community or channel name or image change
5. Somebody likes a message
That's a lot of stuff to key by
@mxstbr yeah. Note that instead of having a key that's unique for all those things, you could manually invalidate the cache whenever one of these things changes. But either way, that requires your data model to have relations between each of these points and the pages which are affected (but I guess it already has those relations in order to build the page contents).
One extra thought I had is that even with the caching, isn't the user is forced to load data from an origin server (on Now)? I.e. it can be a quite long trip introducing latency if someone is located far away from the origin server. Do you have some kind of server replication across different regions? Or would you consider doing CDN edge-level caching, e.g. with CloudFlare's new Workers beta feature? (https://www.cloudflare.com/products/cloudflare-workers/) (that would somehow require the edge caches to be informed about cache invalidation as well)
Additional question, why not using service workers for unauthenticated visitors as well? Might offer an extra perf improvement on top of what the article describes, and it could also solve this caching issue for returning visitors.
What sort of fallbacks do you have in place for browsers that don't support service workers ? I've found SSR to be a lot more of a mindf* when simultaneously dealing with auth and data fetching, so the service worker/app shell solution sounds appealing but I was under the impression it still wasn't supported in some browsers (IE) - is there a simple polyfill or do you fall back to a whole different method/exp for users who can't have the page served by SWs ?
I'm currently in the early stages of architecting something not too dissimilar from Spectrum (in the sense of also including chat/thread structures) and I wanted to try SSR with Next but handling auth flows has taken me a few days to wrap my head around (doesn't seem like there's a ton of info out there for how that works in Next, besides the barebones example implementations in the Next repo). While it doesn't cover auth, your article really couldn't have come at a more perfect time - so dense in useful information/techniques/ideas. So thanks a lot.
In our case that's redis, but it depends on where you want to cache. That code is just illustratory ☺️