meteor / meteor-feature-requests

A tracker for Meteor issues that are requests for new functionality, not bugs.
Other
89 stars 3 forks source link

Update workflow of Meteor.subscribe in DDP #340

Open lh0x00 opened 5 years ago

lh0x00 commented 5 years ago

Reduce the connection when creating a subscribe. Currently in the client, when calling a subscribe. We will create a recurrent subscription and start the workflow, every time we call subscribe the thing, even if the same subscribe was called elsewhere in the page.

Example

/**
 * Server-side
 */
Meteor.publish('_test', function (id) {
  // do somethings.
  Meteor._sleepForMs(1000 * 5);
  return this.ready();
});

/**
 * Client-side
 */

// call in component A:
Meteor.subscribe('_test', 'hello');

// call in component B:
Meteor.subscribe('_test', 'hello');

Right now, we see that the system has done some unnecessary things such as sending requests to the server, server working, waiting to be returned from the server ... but everything can be reused! Some have blamed this by finding the best data structure solution by mistake, just calling subscribe on root components! It's a waste of time and the complexity of the project makes things even more difficult!

Solution

Currently, I have created this package lamhieu:hypersubs to solve this problem. I think it needs to update core of ddp-client! If we find this necessary, I can help update them!

radekmie commented 5 years ago

I've already proposed such a solution (well, with a small difference) over two years ago: meteor/meteor#7878 (PR: meteor/meteor#7889). The difference is, that my solution still ran the server code, as publications don't have to be pure (you can read more on it in the referenced issue). This proposal might be even more problematic, as such subscription won't reach the server.

lh0x00 commented 5 years ago

That's exactly what I want, because if it's sent down to the server then the operation is completely meaningless! You can refer to my package to better understand how I handle it!

mitar commented 5 years ago

Many packages to handle this were already made in the past. It is called "subscription manager" and for different types of apps different kinds of granularity people prefer. As you see this can be easily solved with a package, so not sure why this should be in Meteor core?

See one old package: https://github.com/kadirahq/subs-manager

lh0x00 commented 5 years ago

hi @mitar , the package you provide looks different, the problem we see is that we call Meteor.subscribe multiple times with the same argument! Inadvertently we have created many connections to some unnecessary hosts! it is a problem. You can optimize it, so why not? The package I provided has solved that problem, but I think we should bring it to Meteor core! ref https://github.com/lamhieu-vk/hypersubs