Hi. I have an e-commerce app that uses flow-router and a mix of Blaze and React.
I have only 1 route, not requiring authentication, that I would like to use SSR on, in order to improve loading time (currently around 10s). I’m in the process of refactoring that page so it uses only React.
Would it be easy to use one of these SSR solutions on only one route, while keeping my existing configuration for the rest of the app?
For initial state of collections used all over the app, I like to inject their data in the HTML payload. I synchronize them on time basis.
For the other collection, I basically starts empty and fill them once the subscription is done. I haven’t tried tried yet to use redux-persist but that sound like a good way to avoid reloading all the data, especially when the network does not allow to do so.
For your only one route and with an already setup router, I would use MDG’s webapp. By analysing req.url you could render either your landing page for ‘/’ or a simple spinner for the other.
The Webapp atmosphere page points to a non-existing documentation page. Same on the github repo page. Do you happen to know where these docs have been moved to?
Perfect, thanks! This is what I was looking for. Did not know that Webapp was part of the official Meteor docs.
Thanks for your response! I never thought to look into webapp.
The route that I want to render server-side is not a landing page, it’s a product page so it does need some data depending on route params. But yes webapp seems like a good start to handle that route differently from the rest of the app, I’ll look into it. Thanks!
“Future proof” in Javascript is a bit like chasing rainbows.
@PolGuixe: For those who asked for a maintained react-router-ssr, I’m using the fork jasonnathan:react-router-ssr which has been updated and is working great with latest React etc.
I’m using:
and I am very happy with it. Fast render times, fast empty-cache first page renders, etc.
You can check out my development site dev.speako.ca for a working (most of the time) example of the result. You should see the first render within 1s and then when a webfont arrives it will repaint once. As the big 1MB script file loads in the background you can still do basic interactions like open the mobile menu thanks to inlined script that coordinates with react as it boots up.
For me in Vancouver on an empty cache served from a $10/m DO droplet:
To improve performance, I wrote two more modules that:
async
I feel this solution is as about as future proof as the churny JS world gets these days. All of these packages are currently maintained. All of them have a big active following except react-router-ssr which is the weak link but that whole package is only 450 lines including comments (so not out of the question to include a project scope) and supposedly already plays nice with Apollo.
Super nice 
For our SSR package, I’ve setup a demo on a free tiers: https://demo-xseptfpdip.now.sh/
It scores 91 on mobile and 97 on desktop. Not bad.
The demo content is equivalent to react-router-4 demos with some additions specific to Meteor’s collections & methods. You can also test the REST api capability at /api/ready/.
Can you explain what all this Meteor + Express is about? Don’t Meteor and Express overlap in a very messy way? Are you only using Meteor as a backend and Express for the front? Why?
The demo appears sick at the moment.
Meteor provides a connect. Express is a well known server which sits on top of connect. Using both, Meteor & Express allows you to easily creates webhooks, REST endpoints, … Basically, it provides a Picker like capability to Meteor 
We have also added basic routes used for SEO: robots.txt & sitemap.xml, namely.