Subscription Cache / Manager. Which one are you using?

packages
1

Hi guys,

a little survey: which subscription-manager/cache are you using?

So far I found
The trusted source for JavaScript packages, Meteor.js resources and tools | Atmosphere (dead)
The trusted source for JavaScript packages, Meteor.js resources and tools | Atmosphere (alive, but buggy imo)
The trusted source for JavaScript packages, Meteor.js resources and tools | Atmosphere (alive, but buggy imo)

Any tips?

2

I’ve been using https://atmospherejs.com/ccorcos/subs-cache for a while, haven’t had any issues so far, can you tell us what has been your problem with it?

1 Like
3

My main issue with this package is https://github.com/ccorcos/meteor-subs-cache/issues/20
Plus a little weirdo like https://github.com/ccorcos/meteor-subs-cache/issues/65.

The fork seems more stable, BUT also has the .ready()-issue and just is unstable when clicking back and forth

4

I have not had any issues with subs-manager. It may be dead, but it still works fine as far as I can tell.

Edit: I am still using old school tech (iron router with blaze)

1 Like
5

In my React UI I use onReady() callback instead of tracking ready() reactively. Seems to work well, do you use Blaze?

6

@nickgudumac: Yeah the problems occur on blaze. Actually after switching to subs-manager I am quite happy. It simply works, though I can imagine some use-cases where I’d like to have more control about individual subscriptions.

7

I just got into adding subscription managers and I’m finding that ccorcos:subs-cache is working much better than meteorhacks:subs-manager.

And I do some funky things like stopping and starting. The stopNow() method is nice in ccorcos’ package. meteorhacks:subs-manager through a lot of DOM errors and wasn’t waiting properly.

2 Likes
8

After some weeks of testing ccorcos:subs-cache I have noticed that the subsCache.ready() doesn’t work well when navigating back and forth over templates. It tests if all of your cached subscriptions are ready in a single call. Would be nice if it worked better.

But checking individual cached subscriptions sub.ready() seems to work well. And you can use this pretty easily to check all cached subscriptions on a given template.

2 Likes
9

I think I may have run into an overall design limitation when using cached subscriptions. They appear to not work well with pagination.

If you use a subscription cache for paging through documents using a skip, limit, and sort, for example, as you page through the documents, those documents will get retained and build up in minimongo on the client.

You’ll then need to update your client code to paginate through them correctly. Where with just using regular pub/sub you only have the current page of documents on the client, so you code can just return the currently published set of documents (which is really the current page).

If you update your client code to pass skip, limit, and sort to a minimongo query, in order to retrieve the correct page of documents from all the cached documents, it works with all the overly published cached documents. But what happens when the cached subscriptions expire in the middle of all this?

Seems like that would throw a wrench into everything… like sand shifting underneath your minimongo code.