Skip to content

Instantly share code, notes, and snippets.

Wouter Soudan rhythmus

Block or report user

Report or block rhythmus

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile


Meteor is great at sharing code between different builds for different platforms. You can use the same source for your browser builds, server builds, your builds for iOS, Android, ... But how to organize your project to orchestrate your builds for different use cases? This post elaborates on the reasons why you need these different builds and how you could accomplish this with Meteor easily.

Use cases: Why would you build different apps?

1. Different apps for different roles

Say you have an app with completely different end user experiences depending on their role. It is common practice to have the user logged in, check her authorization (role) and then setup different routes or load different templates to serve that type of user’s needs. While doing so, all types of users load the same build and the app decides what portions of the build to use and what not to use.

rhythmus /
Last active Nov 28, 2015 — forked from Sewdn/
Query Collections

Query Collections

How to reactively change a resultset when a query’s parameters change


A query defines a set of conditions on a collection of documents. Most of the time, only the documents that meet these conditions need to be published to the client. In many cases the query’s conditions are subject to the state of the application (for instance the selected sorting field). This pattern describes how to update your query’s result set reactively without losing the cursor’s state. This way, results are preserved over different adjustements of a query if they meet both set of conditions.

An example case

You can’t perform that action at this time.