Currently, I am using FlowRouter for routing. Now, I am in need for server-side rendering. For instance, I would like to send og:image meta tags for Twitter and Facebook alongside with certain pages (e.g. user profiles).
I know that FlowRouter in general is somehow deprecated since Kadira left the community, but still, there’s no better router around, at least for Blaze. So I am asking myself if I can “risk” to switch from flowrouter to flowrouter-ssr.
Does anybody know about the actual state of this project, i.e. how “reliable” it is, any incompatibilities with FlowRouter or major bugs? The issue list is quite long. All my subscriptions are done on template-level, so this incompatibility to FlowRouter 2.0 would be no problem for me.
Should there be other alternatives to achieve SSR, please let me know Thanks.
(BTW: Has anybody already volunteered to either take over flowrouter or flowrouter-ssr? I am wondering how MDG will deal with the problem that vital parts of the Meteor ecosystem, like routing, are now somewhat deprecated.)
If you are using Blaze, you won’t be able to do server side rendering with flow-router. According to the docs, at least. (I could be mistaken, though).
@mitar’s Blaze Components also supports server side rendering (https://github.com/peerlibrary/meteor-blaze-components). Unfortunately, I have no idea how well it works or how to go about implementing it because I have never used it. (Sorry @mitar!! I love your work, though!)
Thanks for your fast reply and pointing me to the packages.
(It’s really a pitty how the Meteor community is fragmented now. How I loved those days where every package “just worked”, without any caveats regarding Blaze, Angular, React, GraphQL…)
Been using it for a month or two without issue. One thing to note is that if you have a permissions scheme for visibility (restricting access to paid users, etc), you will need to account for that, as this sets up your routes to be publicly scrapeable.
It’s funny that you posted this today, because I spent several hours studying server side rendering with meteor last night. Good timing! I basically just regurgitated my findings. I feel like an expert now! But yeah, I hit the same pain points and had very similar thoughts (at least in regards to this topic).
Actually, my biggest wish with Meteor would be to see an integration on the level of Next and Electrode. I think they do some very interesting things to optimize page loads and support SEO/SSR. I am really curious and interested as to how that integration could/should work.
If you are only interested in SEO, prerender might be an options. I say “might” because I recall @joshowens saying before that he had some problems integrating it. Unfortunately, I don’t recall where or how to find it again… I think it may have been in a post about the Crater.io relaunch and why he opted for SSR. I’d hate to misrepresent his words, so I tagged him in case he would like to clear anything up on that.
I wasn’t interested in paying a monthly fee for prerender.io just to get SEO working. On top of that, I deployed a prerender server of my own on digital ocean using docker, on a 1gb droplet and found that it wasn’t stable/fast enough and Google was showing a good bit of 502 errors in their logs
Moving to SSR dramatically improved my error rates and speeds, but the caveat is that you need to really be careful and figure out a way to get some caching in front of the SSR server to ensure you don’t overrun the server. SSR just moves the processing time and CPU usage from the browser to the server, which can be dangerous.
It’s in its infancy but it already displays react-router@4 demo. It’s based on React + React-router + Express, … and of course Meteor.
I plan on handling server side caching of templates with Electrode caching mechanism, data caching, service worker and application cache (for iOS, Safari & IE).
It is React, so Meteor-React-Router-SSR package, works great. Hit one weird snag with an html comment getting tangled up with the fast render injector, but removed the comment and everything started working.
Also, I will say it again, please make sure to put caching in place if you turn on SSR… At least on some level.
Thanks for the additional infos! Guess I will have to switch to React now (or give Picker a try instead)… May I additionally ask you what you are using for caching Crater? Probably a cache built right into the web server, e.g. nginx?
Interesting. Would it be possible to use this as an additional router for just SSR, or do I have to swtich everything to React to make it work. I am using Blaze + FlowRouter for client-side routing at the moment.
Actually, this solution provides the router. It’s deep linked to react-router@4 and its match capabilities. Plus, the planned caching will take one of the most interesting part of Electrode.
It could be doable to recreate a router that matches react-router client & server capabilities. Identically, recreating a caching strategy for Blaze is also doable as Templates can be rendered to string. But… well, that would require a lot of work.
So I can say everything related to Meteor is deprecated in these days, so maybe the meteor itself is deprecated. I was trying to move from blaze to react myself too and in the middle of process I find out that many react related packages are not getting updated any more and thus I’m currently in process of leaving meteor.
Thanks.