• Meteor
  • Tutorial

Get Your Facts Straight

In this episode, we'll take a sneak preview of a package called, facts, which is on the development branch of Meteor. Facts is a really cool package that lets you publish internal and custom app statistics. First, since we're working on the development branch of Meteor you'll want to go to your GIT clone of the Meteor project, and make sure that you've checked out the development branch.

We're already on development, so we're good to go. Next, I'll create a new Meteor project using the GIT checkout of Meteor. So I can type all of this out, but I actually have a bash function written called devmeteor that points to the GIT checkout of Meteor.

To use the facts package we just need to add it. Next, I'll remove the autopublish package. So we can get a better sense of what's going on, we're going to publish out our collections manually. I filled out some of the code of this application. First, I'll create a collection called Items. And on the server I'll seed it with five items with various titles. Then on the client, we have a template called items which will return a cursor to the items collection.

In the HTML, we'll just create an unordered list and loop over all of the items and create a list item for each item with a title. Next, on the server let's publish out our data. I'll create a publication called Items, and we'll just return a cursor on the Items collection. And then up in the client section, let's subscribe to the items publication.

Great, our simple application is working in the browser. Now let's use the facts package and see what it can do. Just by adding the facts package we get a template. And the template is called serverFacts. This will print out a list of facts that are being published by the server. All right, just to make it a little bit easier to find, let's create a header here called Server Facts. And we'll head over to the browser.

It looks like I don't have any Server Facts quite yet. And that's because I need to set a user ID filter. Let's go back to our code and do that. To do that in the server side I can say Facts.setUserIdFilter. Let me double check that. And then pass a function as a parameter that, itself, takes a User ID as a parameter.

So what we could do here is return true if we want this connected client or this User ID to be able to see the server side facts. For now, since we're just playing around with the package, I'll return true for all users. Great, now we're getting some Server Facts that are being published from the server. They're organized by package.

You can see the first package that we're collecting facts on is, livedata. And the second package that we're collecting facts on is mongo-livedata. Beneath that you can see various things that we're collecting stats on. Right now, we have one active session, two active subscriptions, and one crossbar listener.

In the Mongo-livedata package, you can see we have one live result set and one observe handle. If I add another browser, you can see the number of sessions jumps to two. And the number of subscriptions jumps to four. And the number of live result sets stays at one. That's because we only have one unique cursor that's being published out. So both of these connected clients are sharing that live result set. And you can see that we have two observe handles on that live result set, because we have two connected clients.

So you should, immediately, be seeing how useful this can be, especially if you're building an application that's nontrivial. Next, let's take a look at the data model for Server Facts. The client side collection for facts is stored in the facts namespace under server. So let's query that collection, and take a look at all of its contents.

Right now you can see there's two objects in the collection, one for each package that we're collecting statistics on, or facts. So the ID for the document in the collection is the name of the package. The first object here is livedata. And the second one is mongo-livedata. Those are both packages that use the facts package to publish statistics.

On the livedata package, you can see that we have properties for each thing that we want to track. And so, for example, we have crossbar listeners and the count is one. And sessions, the count is one. And subscriptions the count is two. And then over in mongo- livedata you can see live result sets has a count of one, and observe handles has a count of one.

Next let me show you how a package is able to use the facts package to publish information. You can see the mongo-livedata package inside of the package js file has an api.use call. And it says that it's using the facts package on the server, and it's a weak dependency. In other words, use it if it's available, otherwise don't worry about it.

Inside of the mongo driver you can see how the facts package is used. In this case, this line checks to see whether the package facts exists. And if it does, calls a method incrementServerFact. And as the first parameter it passes the name of the package. As the second the name of that property, or attribute, that we want to increment. And then an integer that indicates how much we want to increment or decrement the count by. And over in the facts package itself you can see where the facts publication is created.

So this is a simple package, but a powerful one, because other packages can depend on it weakly and then use it to publish statistics. Then clients can subscribe to the facts subscription. And the client could be a browser, but it could also be another server. So for instance, you may have a server that just connects to your Meteor applications and subscribes to the facts publication, taking a snapshot every couple of seconds. I'm sure if you can use your imagination you'll find lots of uses for the facts package. Have a great weekend.