Are there plans for implementing SSR?

[tmpg]

Hey, guys love the repo. Especially the new 1.5 features.

Are there plans for implementing SSR?

Thanks,
TMPG

[dr-dimitru]

Hello @tmpg ,

Thank you for interest.

1. Could you describe your use case please?
2. Why other SSR solution couldn't be used as separate package?

[tmpg]

1.Could you describe your use case please?
I used to use (kadira:flow-router-ssr) package but since kadira shut down I swapped over to your package because I needed some of your functionality. For the case example refer to: kadira:flow-router-ssr.

2.Why other SSR solution couldn't be used as separate package?
I can't fine a good solution. If you guys have one I'd love to know.

[dr-dimitru]

@tmpg I meant what for you've used server rendering, what the purpose? Emails? SEO? Is there any other purpose?

[dr-dimitru]

@tmpg we're using meteor-ssr

[dr-dimitru]

@jborseth with code splitting in Meteor 1.5 apps is lightweight and load blazing fast.
What you have described sounds like request to support fast-render, not SSR, am I right?

[dr-dimitru]

Hello @jborseth and @tmpg ,

I'm wondering:

1. How SSR should behave in case of access to page which requires authentication or other user action?
2. How the application state is transferred to Client, like - it's rendered, but JS has continuous runtime how to transfer its state?
3. We may render Blaze template on Server and respond with DOM string, which in this case is static HTML, with no JS listeners, runtime, etc. If we will respond with rendered HTML page, and then request app's bundle, run it and render template again but this time on a Client. Is this expected behavior?

Questions may sound obvious, but we need to make sure we are on the same page. Thank you.

[bensventures]

Just to add to the conversation. We are also using FlowRouter SSR in our React + Meteor app. The primary goal was SEO. We forked the original FlowRouterSSR branch when Kadira announced it was stopping support for it: https://github.com/bensventures/flow-router (Works up to Meteor 1.5, not tested in 1.6 yet)

Trying to give some answers to your questions above:

1. SSR is active only on routes you also include from the server. I think each app should decide to include or not the pages that should be rendered on the server. SSR for profile pages works for us, I think thanks to fast-render.

2. If I'm not mistaken, FlowRouterSSR uses features from Fast-render to get the state of the app and send state + rendered html to the client on first load.

3. React handle SSR automatically I think. Your app sends rendered html without listeners, React inits on top of that, detecting rendered element and adding only what it needs to them. Not sure how this would work with Blaze.

Historically FlowRouterSSR only worked with React I believe. It would of course be nice to have it working with both Blaze and React. And in a less hacky way than what it is now. I had to look at the code to get it to work with 1.5 and the SSR branch feels more like a hack with fast-render than a real SSR implementation.

[dr-dimitru]

Related to #47 - add FastRender support, where is partially implemented SSR.

[macrozone]

SSR makes also sense for stuff like facebook crawler, which uses og-tags to read information. But unfortunatly as of october 2018, the facebook crawler still does not interpret javascript.

With react, its usually pretty easy to do SSR, so i thinking about switching to react-router for that, but it would be awesome if FlowRouter would support it. I think it's not that hard with the new meteor api.

[dr-dimitru]

@macrozone why you need this on router level? It's possible to implement on app-level with the new meteor api, right?

Although, SSR will add tags to head it wouldn't be good for SEO due to Cloaking. You don't need to waste time and resources on implementing SSR, better use self hosted Prerendering or SaaS Prerendering solution

[macrozone]

@dr-dimitru of course this needs to be on the router level, because you don't want to specify all routes twice (one on server and one on client). But maybe i try to do some proof-of-concept at the weekend...

I don't understand the cloaking argument. That's definitly not cloaking.

Yes, prerenders work as well, but you won't get the other advantages like even faster page loads. SSR is not wasted time and resources, its the right way to go. Prerendering is just a workaround.

[macrozone]

one idea:

FastRender.onPageLoad(sink => {
  console.log(sink);
  console.log(FlowRouter);
  const currentRoute = FlowRouter._routes.find(
    route => .... // find the right route
  )
  if(currentRoute) {
  /* now action should be isomorphly defined. On the client it should just mount the component (flow router uses probably still have react-mounter) and on the server it should call   sink.renderIntoElementById('react-root', renderToString(<ComponentDefinedInAction />));
*/
     currentRoute.action(...., {sink})
  }

});

i currently stuck at finding the right route from sink.request.url. This is done with page.js on the client with some fancy regex. But i try now to find out, whether i can use the same logic on the server

[dr-dimitru]

@macrozone what actually do you need to compare against sink.request.url? Or what do you need to get out of the sink.request.url? Route name?

[macrozone]

@dr-dimitru I got it, i will open up a PR soon.

[dr-dimitru]

Hello everyone, thank you for the patience here 🙃

Please take a look and try v3.6.1, where we merged #58 introducing Basic SSR API, thanks to @macrozone and @coagmano

[dr-dimitru]

Hello @tmpg @macrozone @coagmano @tmpg @bensventures ,

Friendly ping on this one. What its status? Is it implemented and working properly?

[macrozone]

@dr-dimitru yes, it works. But i only use it in one project, which still uses FlowRouter and Meteor-collections