Meteor Tutorial

Bring your ideas to life with Meteor

Matthew Platts

Contents

- Introduction

- Chapter 1 Overview

- 1.1 A quick note from the author

- 1.2 Meteor from above

- 1.3 The Seven Principles

- 1.4 Javascript Everywhere

- 1.5 Preprocessing and Minification

- 1.6 Collections and Templating

- 1.7 Data syncing

- 1.8 Two Databases

- Chapter 2 A Simple App (part 1)

- 2.1 Core resources

- 2.2 Setup and Structure

- 2.2.1 foosboom-meteor.html (Listing 2.1)

- 2.2.2 foosboom-meteor.js (Listing 2.2)

- 2.2.3 foosboom-meteor.css (Listing 2.3)

- 2.2.4 Run your app

- 2.3 Structuring your app

- 2.4 Templates and Spacebars

- 2.4.1 main.html

- 2.4.2 A Template

- 2.4.3 Rendering Data with Helpers

- 2.5 Collections

- 2.5.1 MongoDB

- 2.5.2 What is a collection?

- 2.5.3 Mongo vs Minimongo

- 2.5.4 Our first collection

- 2.5.5 Loading our collection into our template

- 2.5.6 Mongol

- 2.5.7 Seed data

- 2.5.8 Publishing data

- 2.6 CRUD Teams

- 2.6.1 Reactivity

- 2.6.2 Session

- 2.6.3 Events

- Chapter 3 A Simple App (part 2)

- 3.1 Database design

- 3.1.1 Normalization vs Denormalization

- 3.1.2 Design your schema to suit your app’s data access patterns

- 3.1.3 Our database design options

- 3.2 CRUD Games

- 3.2.1 Games collection

- 3.2.2 Meteor Mongo

- 3.2.3 Robomongo

- 3.2.4 Publishing our games

- 3.2.5 Subscribing to our games

- 3.2.6 Showing our games

- 3.2.7 Adding games

- 3.2.8 Editing and deleting games

- 3.2.9 The games cache

- 3.2.10 Team name integrity

- 3.3 Accounts

- 3.3.1 Accounts packages

- 3.3.2 Permissions

- 3.3.3 Modifying our teams to work with users

- 3.3.4 Modifying our games to work with users

- Chapter 4 A Simple App (part 3)

- 4.1 Methods

- 4.1.1 A remote function

- 4.1.2 Throwing and Catching

- 4.1.3 Meteor.Error

- 4.1.4 Typechecking

- 4.1.5 Is the user signed in?

- 4.1.6 Meteor.call from the client

- 4.1.7 A second method

- 4.2 Routes

- 4.2.1 Layout

- 4.2.2 Teams route

- 4.2.3 Menu

- 4.2.4 Loading

- 4.2.5 Force login

- 4.3 Collection2 Package

- 4.3.1 The world of community packages

- 4.3.2 Data integrity

- 4.3.3 Adding our first schema

- 4.3.4 Unique title

- 4.3.5 Maximum length

- 4.3.6 updatedAt, createdAt

- 4.3.7 Games schema

Introduction

Welcome to Meteor Tutorial.  The purpose of this course is to teach you how to build awesome web applications with lightning speed.

The Meteor Tutorial, like most programming courses, takes an incremental approach to teaching Meteor.  The first chapter will be a quick and easy overview of Meteor.  The purpose is to help people decide whether they want to continue learning the skill of creating Meteor apps.

In the second, third and fourth chapters I’ll create an app that takes you through the basics of Meteor: templates, collections, reactivity, session etc.  I take it very easy so newcomers don’t miss anything - the more experienced developers should be able to breeze through.

Chapters 4 and beyond aim to cover building an app that is more likely to be built by a professional.  I explain how to use some of the more popular packages to save time and not reinvent the wheel.  I’ll write tests as I go along.

Chapter 1

Overview

1.1 A quick note from the author

Hi Meteor Learners,

I’m releasing this course bit by bit as I go.  I work 3 days a week on this, releasing new versions when I can.  You can find out when I release more content by either joining my email list or following me on Twitter.

Also, since I’m releasing in this fashion, this course can be influenced by you the reader.  Please let me know your thoughts - what you’d like to learn more of, issues with the course so far, etc.  I want this course to grow organically with the community so it can be the best Meteor resource out there!

Thanks, Matt

1.2 Meteor from above

Before jumping into coding an application, let’s look at Meteor from a high level.  How does Meteor work?  Where does it fit in compared to other frameworks?

Figure 1.1:   Meteor has it’s fingers in a lot of the stack pie.

1.3 The Seven Principles

Meteor provides seven principles it abides by, which I’ll copy out here:

- Data on the Wire.  Meteor doesn’t send HTML over the network.  The server sends data and lets the client render it.

- One Language.  Meteor lets you write both the client and the server parts of your application in JavaScript.

- Database Everywhere.  You can use the same methods to access your database from the client or the server.

- Latency Compensation.  On the client, Meteor prefetches data and simulates models to make it look like server method calls return instantly.

- Full Stack Reactivity.  In Meteor, realtime is the default.  All layers, from database to template, update themselves automatically when necessary.

- Embrace the Ecosystem.  Meteor is open source and integrates with existing open source tools and frameworks.

- Simplicity Equals Productivity.  The best way to make something seem simple is to have it actually be simple.  Meteor’s main functionality has clean, classically beautiful APIs.

1.4 Javascript Everywhere

Meteor prides itself on allowing developers to write both their front end and back end code in one language: Javascript.

Folder names matter to Meteor.  Anything you put in a folder called ‘server’ will only be run on the server.  And anything in a ‘client’ folder will be run on the client.  Code in other folders, such as ‘lib’, are run on both (yes you will be writing code that is run on both - defining your data collections, for example).

You are not limited to folder naming; even in files outside of these ‘server’ and ‘client’ folders, you can simply write:

if(Meteor.isClient){

// do client stuff

}

// OR

if(Meteor.isServer){

// do server stuff

}

1.5 Preprocessing and Minification

You can just write Javascript/CSS files and don’t even have to include them in the head of your page - Meteor rounds them all up, minifies them and puts them in your app for you.

Like coding in Coffeescript or Sass?  Well Meteor has a package manager - kind of like Ruby Gems or Sublime Text packages.  You can type meteor add coffeescript in the terminal and suddenly you can write all your Javascript in Coffeescript - it just works.

At this time in writing there are over 4000 packages available.  Note that a lot of them are likely untested or plain unuseful - but you will soon acquire a list of must-have packages.  I’ll be introducing you to the ones I use along the way.

1.6 Collections and Templating

Meteor’s collections are wrappers for your data and stay almost perfectly in sync with the server.  Change your data on the server and you’ll see it change in your browser!

Meteor has it’s own templating system called Spacebars.  It’s basically Handlebars, but built to minimize DOM manipulations to keep things speedy (kind of like Facebook’s React).

No need to worry about compiling the templates.  Just create html files and code away - Meteor collects them up just like it does with your Javascript and CSS - it just works straight off the bat.  Getting excited yet?

1.7 Data syncing

What Meteor is especially good at is keeping data in sync between server and all of it’s clients (good for chat rooms):

Figure 1.2:   Client and Server communicate well in Meteor.

As the diagram shows, Meteor uses websockets coupled with a protocol called DDP (distributed data protocol).  This replaces the traditional HTTP protocol.

Think of client and server like husband and wife.  With traditional HTTP fights would emerge because client did all the talking and server kept forgetting what the conversation was about.  Server also withheld certain information - like not telling when the database has been updated by someone else.

Luckily they went to therapy, which allowed them to now use websockets with DDP. From then on client and server got along like a house on fire - they tell each other everything.

1.8 Two Databases

In Meteor we have Mongo and Minimongo.  Mongo is on the server and is a true representation of the data.  Whereas Minimongo is a Javascript library sitting on the client pretending to be a database.  Minimongo usually only has a subset of the data from Mongo (unless you decide to publish all the data in a collection to the client), but whatever data you publish will keep very nicely in sync with Mongo’s version.  It does this by communicating any data changes using the DDP messages I mentioned above.

Figure 1.3:   How data is synchronised in Meteor.

In the next chapter we’ll start building a Meteor application.  Onwards!

Table of Contents

Frontmatter

Chapter 1