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.
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
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.
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.
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.