Getting started with Meteor [part 1]

Meteor is an awesome full-stack JavaScript framework that allows you to build real-time applications. The code you write can be shared between the front-end and back-end or specifically for either. That doesn't even cover a small fraction of what it can do, but I don't want this to be some lengthy post about how cool it is. I will focus on how to use it. I will be writing a few posts in addition to this one that progressively get more in depth.

One more thing if you aren't in to getting your hands dirty with the terminal and just want to try this out in a hurry head on over to meteorpad.com. It's a pre setup environment fully contained in your browser to get you started learning some meteor goodness.

So without further ado, here is what I've gathered as the how to get started with Meteor and some best practices (feel free to correct me in the comments, and I'll be sure to update the post).

1. Install meteor by running curl https://install.meteor.com/ | sh in your *nix terminal (for anyone running Windows, follow these instructions).

2. Create a new meteor application by running the command meteor create myApp. This will create a new folder named "myApp" with the bare minimum files to get you started.

If all went well you have just created a brand new meteor application. The output from the previous command should be instructions on how to run your new application. Which should be the commands cd myApp and meteor.

Let's dig into the way we can structure our code into different folders. This allows us to control what code runs on just the server, just the client , or both. Very flexible.

Although you may not need all of the possible folder configurations available, here is the gist of them:

• root (myApp)
  • package.js
  • client
    • compatibility
  • models (not part of meteor docs)
  • private
  • public
  • server
  • tests

root

It is important to know that any files not in meteors key folders will be loaded on both the client and server side. Like the "models" folder which isn't in the docs. I will explain later as to why I added it here.

package.js

This is an optional piece. It is required if you would like to use the built-in testing features of Meteor or you would like to create a package that you can publish to Atmosphere (meteor's package system) and make available to the public.

client

JavaScript, CSS and HTML files in the client folder and any of it's subdirectories will be loaded only to the client.

Some libraries will not load properly due to how Meteor wraps each JavaScript file in a new scope. To solve this problem simply place the library in the "compatibility" folder and Meteor will not wrap it in a new scope. All files in the "compatibility" folder will also be loaded before other JavaScript files.

models

This is where you should put all your model definitions.

This is a folder that isn't necessary, but helps keep your root directory clean. Since it isn't one of Meteor's key folders it will get loaded on both the server and client side.

This allows you to use the same code to query models on the front-end as you do on the back-end. It's quite awesome!

private

The private subdirectory is the place for any files that should be accessible to server code but not served to the client, like private data files.

Like the quote from the Meteor documentation says, the private directory should contain files that the server can access but will not load automatically.

public

This is where you should put any assets like images, PDF's, zip files, or any other file that can't be automatically loaded by Meteor and should just be served up to the client staticly.

server

The server directory should contain all your JavaScript that should be kept privately on the server. For instance you may be using api keys for various online social networks, they should be loaded here and not somewhere the client might be able to access it.

tests

This is where all your testing code should live. This folder is not loaded on the client or the server side.

Other notes

It's also important to note that you can use server and client folders within other folders to separate code. Although, more often then not you might take the approach of separating where code runs with a simple conditional:

if (meteor.isServer) {
	// do some server side stuff
}

or

if (meteor.isClient) {
	// do some client side stuff
}

So we've learned a little about how to structure a meteor app and how files in these various folders will be loaded (or not) differently. In future posts I will shed some light on other awesome features of Meteor and include some samples.