This annotated presentation shows you how to optimize subscriptions while keeping your both users and servers happy at the same time.
Subscriptions management is a common issue with Meteor and sometimes introduces weird issues. That’s why we need to take care of optimizing subscriptions. This guide will give you some tips on where you can optimize your subscriptions effectively.
First we need to understand how subscriptions are handled on the server, which will help us to make good decisions.
In the above publication, a static query has been used. It doesn’t change with the arguments from the subscription, so it creates only one LiveResultSet. Even if you had 20 subscriptions, there would be only one LiveResultSet. This is an advantage because, when a polling takes place, there will be less overhead.
In contrast to the previous publication, this one creates a LiveResultSet for every subscription. So when the polling takes place, it will be much costlier, since we will have many LiveResults.
Practically, it is not possible to avoid these kinds of scenarios all the time. That’s why oplog integration plays such a huge role: it doesn’t do polling and makes subscriptions lightweight in the server
The Meteor server keeps a copy of data (documents) available on each client. It allows Meteor to make better decisions when sending changes to the client. But it also increases the RAM usage, if your data set is large.
Next, we need to understand how subscriptions behave in the client, especially inside a
In the first invalidation round, slug is meteorhacks. It adds two subscriptions to singlePost and postList.
In the next invalidation, slug is oplog. The computation removes the old subscription to singlePost, with meteorhacks as the argument. After that it adds a subscription to singlePost, with oplog as the argument. It does not change the existing subscription to postList.
This feature is one of the core concepts underlying Iron Router’s subscription model.
Iron Router runs on a Single Computation. So when it switches between routes, all the subscriptions made from the previous route are removed, unless they are used in the current route.
Here are three simple subscription optimization rules that will help you build better applications while keeping both users and servers happy.
We should send only the data that a page or user requires. The page will load faster, and less overhead (in terms of memory usage) will be added to the server.
Some subscriptions are meant to be used in multiple pages/routes of your app, so it is wise to keep them open. Otherwise there will be some bandwidth issues and users will have to wait while data gets loaded from the server again.
These are not hard and fast rules: break them whenever necessary.
This is a case study where I review Atmosphere and Telescope in terms of subscription usage.
Subscription Manager is a simple package that allows you to avoid some of the subscription-related issues described in the case study above.
I hope these suggestions will be helpful as you build better quality Meteor applications.