Stellar SPAs with Meteor

Brad Cypert - KCDC 2015

Presenter notes inaccurately reflect what I said during the slides. Bare with me.

Titanium Sponsors

Platinum Sponsors

Gold Sponsors

Huge thanks to our sponsors for KCDC. They made this all possible.

-Mark Andreessen, co-founder of Netscape

“Meteor is what we should have built in 1994 at Netscape”

Mark Andreessen, Netscape. Yeah, if that’s not a quote to get you excited about Meteor, I’m not sure what is.

• Server-side Javascript started a long time ago.

• It was absolutely terrible, until recently.

• Chrome v8 engine

• Node.js built on ^

• Meteor built on ^ but with client side stuff too!

Server-side Javascript really made it’s first “major” appearance in 1994, at Netscape actually. And it was bad. Like, really bad. And it stayed that way, until a few years ago.

Google dropped the Chrome v8 engine, which is what node was built on. What we’re talking about today, Meteor, is built on and around node, but it gives you some client-side goodies too!

• Meteor is different.

• Pub-Sub (Publish, Subscribe).

• Mongo db.

• Persistent data connection (DDP)

• ^ made possible via FREE* web sockets.

*Free as long as the user has a valid connection to the server.

Who here is familiar with MVC? Awesome, for the next 45 minutes forget about it. Today, we’re thinking different. The only dominant pattern that Meteor respects is Pub-Sub, or Publish and Subscribe. Data is published from the server, the client subscribes to it, and gets notified when anything changes.

On that note, our data is stored in MongoDB by default. Meteor works best with Mongo, although I’ve heard of people using other NoSQL’s like Cassandra. Eventually, support for common relational databases will be added as well.

All of our data is provided from the server to the client via distributed data protocol, or DDP. Think of it as sockets over HTTP. It’s important to keep in mind that DDP works as expected as long as the user has a stable internet connection.

• Spacebars, Meteor’s templating solution.

• Spacebars is handlebars++

• Handlebars on it’s own can be annoying.

• Meteor solves this problem.

On the frontend, Meteor uses Spacebars, a tempting solution built out of Handlebars. Think of Spacebars as Handlebars on Steroids. Anyone ever used Handlebars outside of Ember-CLI or Meteor? Yeah, it’s a pain, right? Little “<script type=‘text/handlebars’>” tags all over the place. Meteor solves this problem by isolating the template from the JavaScript.

Stop. Two things.

Two things we need to talk about before we live code.

Main.js && Main.html

1

Main.js and Main.html are two files that are built last. Everything in the same folder, or subfolders will be built before them. Why’s this important? In the “Main” files, you’ve access to everything you’ve bootstrapped or defined in the same folder or subfolders. Just remember, “Mains” get built last. Simple enough, right?

Four Folders every Meteor developer should

know about!

2

It’s not a BuzzFeed article, I promise, but you really should know these four folders. They help you structure large scale meteor apps, that aren’t polluted with IF statements. We’ve got a nice graphic to look at here…

server lib client

public

Don’t think too much about it, just focus on the venn diagram. Server and Client are usually separated, right? It’s important to note that lib is shared.

• Server - Backend, serverside JS.

• Client - Frontend, HTML, CSS, JS.

• Lib - Shared resources, references to mongo collections.

• Public - Assets, pictures, external CSS, fonts.

Here you can see exactly what would go in each folder. Server - Backend JavaScript.Client - Markup, CSS, JavaScript.Lib - References to shared resources such as Mongo Collections.Public - Standard public folder, no magic here, just directly serves up assets, pictures, etc.

Let’s Code!

Let’s do this!

Code can be found @ http://www.github.com/bradcypert/KCDC-Demo-App