I’ve been wondering, besides easy SEO, what’s the advantage of server-side rendering? I’m also not clear on how it works, exactly, in the context of Meteor. If you put code in /both instead of /client, then you’re executing the same code on both the server and the client, right? Then aren’t you still making the client do all the rendering work, while also taxing the server’s CPU?
I’ve been having some struggles with SSR:
…so I’m starting to get the feeling I should just remove kadira:flow-router-ssr, go back to the regular version, and get back to work, as this SSR trouble is really side-tracking me. Then of course the SEO issue is still up in the air, as I’ve heard that using the traditional PhantomJS route is very processor intensive when the bots hit.
I’m a little frustrated and hoping someone who knows better than I do has some sage advice. Till then, retreating back to the safety and comfort of client-side land.
SSR is for pages that are the same for all people, if you need authentication for this page to even show then clearly this page shouldnt be rendered on the server
Valid point, and I’ve actually decided to just have nginx serve up the pitch page (public), and since the rest of the entire app is a private service, it doesn’t matter if SEO hits it (actually, it shouldn’t, and won’t be able to).
Still, I was just curious what the advantage of SSR was besides SEO for free.
the advantage beisdes SEO is the fact that the pages can be loaded before your meteor js files are event loaded, provide for a very snappy first time page load, and subsequent pages are loaded via client.
Just wanted to add, if your site is SSR and takes a long time to finish starting you could have an issue where the user can see a button but then nothing happens when they click, until the client is done re-attaching click handlers.
I’m currently building everything in the ‘both’ folder and then only using client routing. Then it’s easier later to turn on an initial SSR. The server does get a copy of the code but i’m not too worried about the larger bundle on the server.
You can also (ideally) use caching with FlowRouter 3 for pages that do not have dynamic data.
Another approach is a hybrid. Send the data with the HTML page as inline script, then on the client, prime the app as needed with this data. The UI is generated as usual and will re-render when the bootstrapped data is primed into the mini-mongo.
I think @arunoda said that FlowRouter 3 will support his as well but i’m not sure.
You can also further reduce the amount of JS being sent to the client by sending only what you need on the initial page, then lazy load the rest. This can be tough to do without something like webpack, and even then is a pain.
SSR Always - Takes a lot of CPU and may be higher latency as well
SSR with Caching - Do a initial SSR and cache it for rest (good for public pages, even they are dynamic)
Fast Rendering - Do a initial SSR for a route and remember patterns of subscriptions and route data. Then invoke Fast Render later on - Good for already loggedIn users
We could ship a beta version of by end of this month.
Any plans for API which would let us bundle some serialized data to be sent from SSR to client?
Similar as fast-render, but custom. Cause I was not able to bundle flux state into <script> so it could be loaded into client.
Or pointer where to look to accomplish that ? fast-render sources ?
Till then, retreating back to the safety and comfort of client-side land.