Meteor is an open-source JavaScript framework written on top of Node.js, used to develop web and mobile applications. It is a tool for developers who want a responsive and real-time updating application without going through all the trouble of setting one up. Meteor is an isomorphic framework, meaning that all environments (i.e. server, web client and mobile client) are developed using the same language (Javascript), and (partially) run the same code.

One of Meteor’s key features is that the developed applications are ‘reactive’, meaning that if a change is made somewhere in the application, the same change is instantly reflected on all connected clients. Because of this, Meteor is a great tool for developing real-time applications. Meteor uses a MongoDB database on the server, and a Minimongo database on the clients, which serve as a cached version of the database. This makes the client faster, and also allows it to update automatically whenever the server’s database is updated.

Meteor is very flexible. Applications can be developed in Javascript, Typescript, Coffeescript, etc. On top of that, different frontend technologies can be used, like Meteor’s own frontend Blaze, Angular, React and Vue. Because Meteor is built on top of Node.js, Meteor has full support for NPM. But besides NPM, Meteor also comes with its own package manager called Atmosphere, which has packages specifically created for Meteor by other developers.

Why investigate Meteor?

We chose to investigate Meteor because for our Bachelor End Project we used Meteor to develop an application to run semi-virtual escape rooms for our client company Raccoon Serious Games.

In short, RSG creates and hosts escape room-like events for companies, where the employees of that company split up into teams and all work on the same physical puzzles. After solving a puzzle, they will have to give their answer to the puzzle on a tablet, and then get up and get the next puzzle. The people who hand out the puzzles have to keep track of which puzzles every team has, which puzzles they’ve solved and which puzzles they should receive. They do all of this on a tablet as well. Lastly, there are also people who walk around the room and help the teams if they need it. They can track a team’s progress, and send them hints, also from a tablet.

We used Meteor to build the application all of these tablets are running. We were able to test this application in practice at an actual event, and the application was taken into use since then, still being used today.

One thing which we really enjoy about Meteor is that it makes developing a reactive system really easy. A lot of the necessary set-up involved is abstracted away by Meteor, so we don’t have to worry about it. But, as you can imagine, we also have a slight love-hate relationship with Meteor. We used it to build our application, but we don’t understand its inner workings. There are things that Meteor does which make a lot of sense, and things that don’t. Our goal with this project is to get a better understanding of why Meteor is the way that it is, and the decisions that drove this process.

Who are we?

  • Ayrton Braam
  • Wouter Morrsink
  • Tim Nederveen
  • Alexander Sterk

More information

The vision which makes Meteor shine

Meteor provides a simple environment in which reactive web and mobile applications can be easily written and built. Meteor is open source, but it is still officially being developed by Meteor Software. It’s a JavaScript framework built using Node.js. One of its core features is its reactiveness, which means that a change in the application is reflected at once on all the other clients. Meteor is isomorphic, meaning that both client and server side can be written in the same language. Furthermore, Meteor allows for different front-end technologies to be used. This all makes Meteor a great framework to create web and/or mobile applications.

The architecture behind Meteor’s impact

In ‘the vision which makes Meteor shine’, we researched the vision behind Meteor. Now the question is, how was this vision realized? For this, the six architectural views have been described by Rozanski and Woods, namely: concurrency, deployment, development, functional, information and operational. In this blog post, we will be taking a closer look at which ones of these are relevant to Meteor and go more into detail on those which are.

Comets and commits: the software quality of Meteor

After discussing the vision of Meteor and its architecture, it is now time to look at how its quality and architectural integrity is retained during development.

Exploring the Atmosphere: the variability of Meteor

Two posts ago, we discussed Meteor’s architecture and its separation into two parts: the Meteor Tool and Meteor Packages. We explained that Meteor’s core functionality is distributed across different, standalone (and sometimes interdependent) packages. There are a number of different packages created by Meteor itself, such as packages for Meteor’s account system or packages for Meteor’s reactivity and connection to MongoDB. There is also the option of third-party packages designed for Meteor, hosted on a platform called Atmosphere.