This is the overwritten version of Meteor subscribe . It optimizes performance by not create connect sent to the server when it is not needed. Hypersubs only creates one connection for multiple subscriptions when detected it is duplicate (same publication name and params). Hypersubs only make a real connection (for the first time call Meteor.subscribe ), since the second times call Meteor.subscribe , they will be optimized reuse the connection is existed!
All the rest of the packages are automatically made for you, no need to change anything in your source code!
5 Likes
I believe this is only the case on an autorun by autorun basis. If you call the subscription in multiple places then it does make a separate call.
1 Like
Wow, I can’t believe I never realized that it didn’t mean it did this by default and that autorun is a special case.
I guess I’ve never had a time when I called a subscribe repeatedly outside an autorun. This does seem like it should be the default core behavior though. I can’t think of a reason that I would want the publication to run more than once.
1 Like
Also, if you have a router level sub then all those subs are torn down on every route change… I think most Meteor apps eventually need a subs manager of some kind. It’s pretty tricky to get right though, especially if it also does caching with timeouts in addition to multiplexing. Proper reference counting is surprisingly difficult. I’ve never found an open source one that works properly so we ended up writing our own.
I don’t think ours will run without additional modification since we use custom functions like _.hashCode, and Blaze.wrap but this is ours: https://gist.github.com/veered/33c1321e21790784fd12a14fb28f5ccc
Hopefully Hypersubs will work for people! It also seems to monkey patch Meteor so that it will automatically work in the app without having to explicitly use the subs manager everywhere.
2 Likes
Meteor just skip for multi subscriptions scope in this Tracker.autorun. If you have 2+ subscriptions with the same name and parameters in other positions, DDP still sent the new message to subscribe and Hypersubs was created to fix this problems (this not is a problem of Meteor core, this is a problem of application). You can try!
Why this not is a problem of Meteor core? Because in the server you can stop a subscription (something you need to do it) and if we reused the connection for all case this will incorrect. You can read more about Hypersubs work here
1 Like
I understand why the package might be necessary given the current implementation. I do however disagree that this isn’t an issue that could be fixed in core. The client is notified when a publication is stopped and therefore should be able to manage this without the need for a third party patch.
2 Likes
I don’t understand it, please help me clarify it.