I’ve been working on a project with the MeteorJS framework for about four months now. The idea is to create a cloud-based design-thinking platform for the enterprise called Basecamp Insights. I don’t plan on open-sourcing this app, so instead I would like to post a few Meteor patterns I have been using throughout my code.
For this first post, let’s start with publications and subscriptions (pub/sub), which are the basic building blocks of any Meteor app.
In Meteor, documents are stored in what are called a collections. The above functions control the flow of documents between the client and the server. Just like their names would suggest, the server determines which documents are published and the client determines which documents are subscribed to. When the client subscribes to a publication, the server sends the relevant documents, and the client stores a copy of each locally. Meteor does the behind the scenes work of keeping the local copies up to date with what is on the server. So here are a few example patterns of pub/sub in Meteor.
This pattern only publishes documents if the client is logged in:
This pattern only publishes documents whose projectId value matches a role that is assigned to the client:
This pattern publishes specific fields from the users collection:
This pattern takes a simple argument. It uses the Underscore contains function to check if the argument is in the user’s roles array and then publishes only documents that match that role:
This pattern can take up to two arguments, and checks for the existence of each before deciding what to do:
This pattern individually adds documents to publish to the client. It publishes one of each of a specific type of document:
You can specify which code is executed on the client and which code is executed on the server using Meteor’s built in directory structure. Anything in the client folder gets executed on the client and anything in the server folder gets executed on the server. You could also use Meteor’s isClient and isServer methods: