Strategies for subscription management (unblock until needed)

help
1

I’ve been enjoying the recent discussion and thoughts on subscription management. Especially template subscription in meteor 1.0.4 and the musings of @arunoda on subscription management.

I typically find that the subscriptions I make fall into one of three different priorities:

  1. The top priority are subscriptions I need to render a layout/ minimally functional page
  2. The next are subscriptions I need to make a widget work that is embedded within said page, but doesn’t necessarily have to be ready at page load
  3. The third are subscriptions I make because I anticipate the user will need them at some time even if they don’t need them immediately (basically to make the app respond in a more native way)

waitOn router based subscriptions work great for the 1st. Template subscriptions and/or waitOn router subscriptions are perfect for the 2nd. But I wanted to get some thoughts about a potential solution for the 3rd.

Would it work to use subs-manager with unblock in the following way.

  1. Do a Tracker.autorun looking for a valid user.
  2. As soon as the user exists do a subscribe to a publication that provides all/most of the collections that user might need in the future. This publish would be non-blocking.
  3. Later on, if that data becomes critical do a subscribe to a similar publication that will return the critical data but without unblocking/yielding.
  4. I would pump all of these into a subManager() instance.

Some questions that come to mind are:

  • If whether to block or not is a parameter passed to the publication, what would happen when calling the same subscription twice, but once with this.unblock being true and later being false (especially if the unblocked version hasn’t finished)?
  • Other strategies to pull largish amounts of data into client side collections without creating blocking DDP connections that could interfere with smaller subscriptions?
2

Shamelessly bumping this in case anyone else has tried or tackled subscriptions in this way.

3

+1 for knowing if someone has achieved “prioritized subscriptions”.

4

The third are subscriptions I make because I anticipate the user will need them at some time even if they don’t need them immediately (basically to make the app respond in a more native way)

I am very curious about how to achieve this kind of scenario as well.
Lately I have restructured my application to switch from loading every collection at startup (via subscriptions option in iron router) to template level subscriptions. I could reduce response times significantly this way. Furthermore by unblocking all publications where possible.

Now I am searching for ways to further improve performance. This use case you mention is quite similar to the method of predictive browser caching. Unfortunately, like you, I couldn’t come up with a suitable way to solve this.

I took into account subs manager package, but it doesn’t seem to work together with template level subscriptions.