By default, we have been using a Meteor package named autopublish. This means that we haven’t had to code specific publishevents for changes to be broadcast from the server to the client. This is great for testing, but we want to have a bit more control over what events and documents get published so that we that can improve both performance and security.
If we have a large dataset, we may not want to return the entire collection every time. If autopublishis being used, the entire collection will return, and this can slow things down or expose data that we don’t want to expose.
Turning off autopublish
The time has come to turn off autopublish. Temporarily stop your Meteor application (if it’s still running) by opening the terminal window from which you ran the meteor command. You can stop it by pressing Ctrl+ C. Once it’s stopped, enter the following command:
meteor remove autopublish
This removes the autopublish package, which is responsible for all the automatic publishing of all events inside Meteor.
It’s considered a best practice to remove autopublishfrom your project. The autopublishpackage is for developing and debugging and should be turned off when you’re ready to start using your application in earnest.
By turning this off, you’ve effectively disabled your application from doing anything! Congratulations! You can see your amazing progress by starting up your Meteor service again (to do this, enter the meteorcommand and press Enter).
I have an app has categories/lists variable, from now i will use this example app to show how to configure publisher
The categories/lists are gone! You can even check the console if you like. To do this, enter the following command:
lists.find().count()
You should see a count value of 6 or more, but you will instead see a count of 0:
What gives? Well, it’s pretty simple actually. Since we removed the autopublish library, the server is no longer able to broadcast changes to the client. Why, again, did we do this? What’s the purpose of breaking our application?
Ah! Because we want to make our application more efficient and secure. Instead of getting every record automatically, we’re going to just get the records that we need and the minimum set of data fields from those records.
Listing Categories
In MyMeteorApp.js file, inside the if(Meteor.isServer) block, create the following Meteor.publish function:
Meteor.startup(function () {
Meteor.publish("Categories", function() {
return lists.find({},{fields:{Category:1}});
});
});
This tells the server to create a Categoriespublication. The server will publish this whenever a change is made to the variables found inside the function; in this case, it’s lists.find(). Whenever a change is made that would affect the results of lists.find(), Meteor will trigger/update the publication.
If you noticed, the lists.find()call isn’t empty. There’s a selector, {fields:{Category:1}}. This selector tells the lists.find()call to only return the specifiedfields:. And only one field is specified—{Category:1}.
The preceding snippet of JSON tells the selector that we want to get the Category field (1= trueand 0= false). Since this is the only field mentioned and it’s set to 1 (true), Meteor assumes that you want to excludeall other properties. If you had only fields set to 0(false), Meteor would assume that you want to includeall the other fields that you didn’t mention.
For more information on the find()function, consult the MongoDB documentation at http://docs.mongodb.org/manual/applications/crud/.
So, if you save this change, your browser will refresh and nothing will happen to the display! Why? As you may have guessed, removing the autopublish library did more than get rid of the publishevents. It also got rid of the listeners/subscribers. We don’t have any subscriber set up to listen on the Categories publication channel. So, we need to add a subscriber event that is tuned in to the Categories channel.
if (Meteor.isClient) {
Meteor.subscribe("Categories");
Save this change and you will now see your Categories back where they belong:
Remember, All the other fields you want to broadcast must be subscribers.
Checking your streamlined data
The display is now no different from when we started this chapter. However, underneath the display, the model is much leaner. With the Clothes category selected, run the following command in the browser console:
lists.findOne({Category:"DVDs"})
Expand Object, and you’ll see that no items are listed:
The reason why there are no items is because our Session variable, current_list, is set to Clothesand not DVDs. The find() function only gets the full record for the current_list. Now, enter the following command in the browser console and press Enter:
lists.findOne({Category:"Clothes"})
Expand Object, and you’ll see your three items in an array:
Click around in the app, add items to categories, add new categories, and check the underlying data model that’s visible on the client. You’ll see that your listsare now much less visible; therefore, they are more secure and discreet. This probably won’t be a problem for your own personal meteor application; however, as we expand this in the next chapter so that multiple people can use the app, the streamlined and discreet data will improve performance.