Making Meteor SSR better

[Grubba27]

Hey guys! we saw many comments on the roadmap forum post(check it out). The topic that was most commented, on at the time of this writing, was Oplog/C. Streams and Redis, there are already discussions for that here in GitHub, and personally I think those topics make sense.
Having said that, this discussion focuses on what the community wants to see for the SSR part.
What I would propose is something in the likes of Inertia.js(PHP and Laravel have been in this game for some time, and they have really interesting ideas).
That API is really good. The only thing I would change is to make it more compatible with JS. Take this pseudocode snippet for an SSR future in Meteor:

Meteor.router.get("/hello", async (req, res) => {
  const someData = await dataFetch();
  return Meteor.render(<ReactComponent someData={someData} />)
})

we could have a config file to make the setup for ssr(react requires, for example, a setup to handle SSR)
This same API could be applied to Blaze, using the same inertia or the react, but then maybe we should bring this idea of SFC to Blaze.

We could have adaptors for Svelte, Vue, and many other Front end frameworks that do support SSR.

What you guys think?

[StorytellerCZ]

Interesting, could this in a way mean that we will have to create an official router for Meteor? For React it would be best if we could tie it in with things like react-router and same in other languages, unless this path would get only triggered if it is the direct entry point into the app and not when the user is already in the app, so that it doesn't trigger SSR when it is not needed.

[Grubba27]

Create an official router for Meteor?

I would go with the idea of a wrapper. We could have wrappers for every front-end framework, which would work similarly.
The main Idea is to have an opinionated and supported main way to do this, which is what makes sense for a framework, with this primitive people could build other things on top routing by folder for example.

[jamauro]

I would go with the idea of a wrapper

Does this mean each front end framework would need to have their own SSR router package that Meteor wraps somehow? I use svelte fwiw so curious if I'd need to find a svelte router that supports SSR.

[Grubba27]

In the Svelte case, if I'm not mistaken we could wrap with the vite-ssr or svelte-routing is been some time since I do not do anything with svelte.
I think meteor could provide the primitives and we could do a community effort to have those integrations

[henriquealbert]

If you're looking to gain a better understanding of Inertia.js + Vue3 + Laravel, Laracasts offers a tutorial that is worth checking out.
Also, utilizing Meteor RPCs would be a more practical approach in our Inertia.js implementation rather than relying on HTTP requests.
I love how easy it is to use Laravel and Inertia.js. It makes everything so much simpler, and we could also have that.

[jamauro]

Would this also work with pub / sub? Or would you render an initial set of data and then have pub / sub take over in the view?

[radekmie]

While I love the idea of having one solution for all frontend layers, I think it's at least a huge thing. I mean, there are whole frameworks that focus only on one of them (let's focus on Next for React and Nuxt for Vue here) and even there SSR is not a trivial thing. Even Vite's SSR is not exactly what I'd expect, because it doesn't handle streaming (and it's crucial for React's <Suspense>; I suppose the same goes for Vue).

Overall, I'd rather go into a per-view layer solution, just like react-meteor-data. I say it also as the creator and maintainer of uniforms that abstract over schemas and UI themes - this is hard already and doesn't have to go around the truly low-level differences between view libraries.

[minhna]

Interesting topic. Do we have any update? I tried renderToPipeableStream on Meteor 3.0 and React 18, it looks promising.