Since I got your attention, maybe you can review Meteor 3.0 compatibility by manueltimita · Pull Request #99 · percolatestudio/publish-counts · GitHub? I’ve applied the changes you’ve requested. Thanks!
Regarding all the discussions here on Oplog, I recently published a PR which also improves the performance aspect of the oplog tailing a lot: New mongo package options to optimize Oplog tailing performance to include/exclude certain collections by Twisterking · Pull Request #13009 · meteor/meteor · GitHub
In regards to packages: We also use Grapher quite heavily at Orderlion, but are now replacing it with the successor @bluelibs/nova - @diaconutheodor and his team really did an awesome job there!
I personally am now a huge friend of Mongo aggregations. When you have multiple collections to “join” and have nested stuff, this can become a huge pain in the a** to get right in my experience.
The Aggregation tab of the recent version of MongoDB compass has been very helpful when creating Aggregation queries
+1 here, RedisOpLog is crucial part. Even for the apps/devs who use reactivity only when absolutely necessary.
2 Likes
We’ve recently started using aggregations more heavily again, particularly with migrations which are really nice to be able to test in Compass. What about with publications though. Have any of you used jcbernack:reactive-aggregate (or edit) tunguska:reactive-aggregate (which seems more up-to-date) ?
I’ve used its successor GitHub - robfallows/tunguska-reactive-aggregate: Reworks jcbernack:reactive-aggregate for ES6/ES7 and Promises in projects before. It worked nicely. I can’t speak to its performance under heavy load though. Curious to hear other experiences.
That is a great idea! So why not remove all publication features from the core and only provide methods?
I think it’s a great idea if you just remove all the unique features of Meteor and adapt Meteor to other frameworks like NextJS. That way we’ll have the 100th Javascript framework with the same features 
2 Likes
Without any heavy load, there is already a significant waiting time due to the way livedata_server.js handles publishing, refer to :
I think @storyteller was economical with the details. The reywood:publish-composite package used to be employed for all sorts of work that GraphQL and a few other tools came to solve in recent times. But reywood:publish-composite remains quite useful in a lot of situations.
If you had a look at the 6 pull requests merged since Oct 2023, some of them pretty large, you’d have a different opinion : Issues · Meteor-Community-Packages/meteor-publish-composite · GitHub
Read the sentence again. The key word is IF. The main point being that you should think about your data. NOWHERE did I mention anything about removing pub/sub (especially from the core - totally ridiculous point in all aspects). Also for when you need them reactivelly the point is to think better on how to manage and structure the data than using reywood:publish-composite and just get everything on the client. If not handled properly this will just create more issues. @illustreets got it right.
This topic is here to suggest packages that have better alternatives, or approaches. Especially if they are legacy or maintainers are not supported properly.
Yes, I’ve read the IF.
**reywood:publish-composite**
Especially if you don’t need the data reactivelly, then it is better to migrate to GraphQL.
That is the point. If we use publish-composite, we NEED the data reactively. So mention a none reactive solution makes no sense here. We have methods for none reactivate data.
Yeah, I understand that. But GraphQL isn’t reactive (out of the box). If there are better packages for publishing multiple collections I would agree with you.
Great then it does not concern your use case (do not assume that everyone is using that package responsively as you do), so why do you assume that I want to remove pub/sub from the core?
Given the age of the package there are many old apps that have pub/sub for all the data and don’t even consider using methods or other non-reactive approaches for data that they don’t need reactivelly.
Others got the point well and we moved on updating publish-composite based on this thread. I don’t understand the hostile tone, why you reached that conclusion, but I’m going to update the opening post to make things more clear for future readers.
Do note, that since there is another thread about this that you have created I will remove any discussion (or if I can figure out how, move it to the other thread) on this topic here as it is off-topic to the thread here and there is other thread to discuss this.
The comment was not meant to be an attack, I respect the work you are doing for the community. The solution you proposed (GraphQL) made me assume that there is no longer a focus on libaries that work with reactive data. And publish-composite is still the proposed solution for relational data. If there is a better package or better solutions that support reactivity, I fully agree with you that publish-composite can be replaced.
Honestly we need a more dedicated maintainer for publish-composite or a newer solution. For many Reactive Aggregations (I do recall seeing a package for that somewhere) I think would cover most use cases, but then there are others where you simply need the data in minimongo in which case I currently don’t know of a better solution. Which is what I hope someone might suggest in this thread.
I’ve been at it for a while, though I cannot claim I know it very well. That package still has secrets as far as I’m concerned. But I didn’t find it hard to work with it either. It’s a combination of time and lots of testing. I’m happy to keep contributing to it for the foreseeable future. We use it in production for a few lightweight, but essential publications of multiple related collections.
or a newer solution
For what it does, provided it’s small scale, hard to see what could replace it.
Some of wish to be helping this but since we are limited in knowledge. If you can give some lesdons on it or if there is a lesson give a link to understand this situations that some of us will start to help. Thanks.
I’m one of those devs who use reactivity only when absolutely necessary but Redis Oplog isn’t crucial for me. I do understand it’s crucial for those who use a lot of pub/sub but it’s not crucial nor necessary if you only have one or two pub/sub and you know how to use use them correctly.
The missing qualifier here is having a busy application requiring multiple server instances. Oplog tailing already eats resources proportional to the number of server instances, even without considering your pub/sub.
1 Like
True, but using this package may improve load sustainability on high-load projects reducing maintenance and servers costs. So it really depends from size of the project and its complexity
1 Like