Fast Render has officially announced that it will no longer support its package.
And officially announced, will hand over the package
Therefore, anyone can seriously support it, announce it in the link above
As a result, restrict the rendering server for now, unless you want to use it without data.
@filipenevola
I must also note again, it is time for the meteor to think fundamentally about the rendering server and its problems.
Otherwise, the work is so terrible forever.
i agree, the whole routing and SSR story should be supported by the core-team, at least for projects using DDP and meteor-collections.
If you are not using DDP, but graphql or similar instead, you can use the same approaches like for non-meteor apps, so thats fine (and i would definitly recommend to use that instead of DDP if you can chose).
But DDP and collections is meteor-only, so there are no solutions around that you can use. In particular the data-hydration and Meteor.userId() problem is something that can only be fixed, when you know the internals of meteor in that area. The fast-render package solved that, but its probably hard to maintain unless you know meteor pretty well.
And my question has always been, does meteor have a plan for these issues?
Can we wait for version 2 to resolve these issues?
I am not involved with this package, since I don’t do SSR. However, I see this package is a fork from the Kadira package and there may be still a good bunche of potential users out there.
Would this package be a useful candidte for Meteor Community Packages (assuming that there are people who can maintain)?
// cc @storyteller
@jkuester
I think we should have more courage.
You do not think it is time for the meteor to have a strong ssr.
The meteor should not attach critical components like this to an ancillary package.
Even transferring it to Meteor Community Packages is not a good thing in my opinion.
I have been watching fast-render package and I’m split on taking it up. In a way I agree with @saeeed here that we should consider improving this in core if feasible. From what I have seen there is a lot that is front-end tech specific, but there might be some wins that we can make in general. But sadly this is all out of my current scope and bandwith.
Can we hope for version 2 that this issue is resolved?
What specifically should be resolved?
For version 2, I think if only the subscribe data problem is solved, it’s a big deal and we can actually use ssr.
If I had the knowledge to do this, I would not hesitate for a moment
Well, here is the problem. I don’t have the knowledge either. I also currently don’t have the need, time or incentive to research it. So unless someone else volunteers to pick it up, don’t expect it in 2.0. Meteor Software has their hands full with HMR, Meteor Cloud and wrapping everything else up.
Tiny has to pick this up in my opinion or at least provide clear guidelines how to do SSR with the old DDP/collections data-layer for react and vue (and maybe blaze if that will ever receive ssr).
SSR is a long existing pain point in meteor that has never been properly tackled. And i would argue that this is one reason why many switched to different platforms (including myself).
@saeeed personal tip: don’t use Meteor-collections/DDP/pub-sub and switch over to graphql if possible.
@macrozone Is pub/sub possible with GraphQL now, and is there a good tutorial to do that switch? I looked it up about 1.5yrs ago and couldn’t find a good approach back then, everything in that field was still pretty premature. Besides, I agree with @saeeed, SSR should be part of Meteor core.
graphql has a subscription type, but it requires some additional setup, but to be honest, i never used it because i never really needed it.
You seldom really need pub/sub (=“realtime” updates). Its nice to have and i loved that about meteor, but it comes at high costs: it makes scaling hard and you can fall into non-obvious pit-falls when you try to scale. You should consider where “realtime” updates are actually required. If you do fleet-tracking, ok, but i guess there are more specialized solutions for that. In some cases realtime-updates can also be annoying for users, e.g. in a message-board.
if you have specific cases for real-time updates, you can also consider polling (some seconds interval). It sounds inefficient, but if you expect regular updates anyway, polling actually leads to roughly the same load on network and server, it is just much simpler and therefore easier to maintain, scale and understand. Or you add a pub/sub channel for specific use cases.
On a side note: in apollo client you do get updates from mutations, optimistic responses and if multiple components fetch the same data, they will be in sync. So, everything the current user is doing, is “in sync” with the backend usually. I think that is what most would expect from “realtime updates” .
If not already clear: i also think SSR, data-hydration with pub/ssub, etc. should be part of meteor core. Many devs still use it (i also think its hard to migrate away from it, i would therefore not recommend to use it in new projects if possible, but thats my personal opinion)
React is already exploring an idea of Server-Components. So I think we should wait and see before moving SSR to meteor-core. Implementing DDP support for SSR might become much easier with Server-Components.
@waldgeist @macrozone
You see, the main idea of the meteor is the pub / sub system, and if we do not use it, there is no reason to use the meteor anymore. If there are problems, they should be solved, not pushed aside.
Anyway, now our main problem is ssr and data sharing in the rendering server.
I ask all those who have this concern or can help in some way to solve this problem, to mention it in the following link.
I agree with you that these issues should be solved in the core. Meteor may be more than just pub/sub, but also for me, it’s an important part. I would have chosen another platform for our current project if pub/sub wasn’t a key element in it.
I know, and I am using this feature wisely. However, there are lots of valid use cases where pub/sub makes sense. It’s also the main reason why I chose Meteor to build our location-based AR platform.
That was already the case a year ago, but I couldn’t get it running (at least with Meteor). Too many parts were missing, or maybe it was just poorly documented. At that time, I had to build a prototype quick.
Maybe, but in this case you will always get the full dataset, unless you have a clever means of transferring only the deltas. This can be quite substantial, especially if you’re using mobile devices.
I agree.
Maybe someone needs to fork Meteor and add it in core, then get adoption of the fork. That may be a better way than a package?
Currently, this is the official package from Meteor related to SSR: https://docs.meteor.com/packages/server-render.html
When I browsed through how we implemented SSR, we used the package above but most of the things we did are specific to React. Therefore, I do not think any additional handling must be in the core but instead must be in a package specific to the front-end the developer is using.
Related to pub-sub, I personally do not see any use of pub-sub related to SSR. When we do SSR, when a case comes up on using pub-sub, all resolutions just ended up in two: it must be a method in such use case, or it must not be displayed in SSR. From experience, there were no use cases for us that requires pub-sub with SSR. (Of course, we have different needs, but when we scrutinize the pub-sub requirements for SSR, our conclusion: it is not needed)