Heroku
First you will want to Sign up for Heroku and install the Heroku Toolbelt (note: I believe the toolbelt may also be installed with a simple gem install heroku command if you have RubyGems on your machine...) which will provide you with a CLI for managing our Heroku app(s).
After you have to Heroku Toolbelt installed, try executing the heroku command from your shell to ensure everything is in order and then login for the first time by running heroku login.
After this is complete, contact me (@Bradley) and I'll add you as a collaborator to our app(s). Obviously we will at some point want to transition to creating a Heroku account for our SummerLeague in general and transfer ownership of our app(s) to it but this works for now.
Heroku provides a full guide for getting started with Heroku and Node.js but I will synthesize the key points here.
After you installed the Heroku Toolbelt, you were given access to Foreman which essentially allows you to declare processes needed to run your application in a Procfile which Foreman will read in order to get your app running. Because we have a Procfile, we can run foreman start from the root of our application directory to start the application. More importantly, this is how Heroku will start our application; the command for which you can see in the Procfile as web: node app.js.
Heroku links your projects based on Heroku git remote. To add your Heroku remote as a remote in your current repository, use the following command:
git remote add heroku [email protected]:project.git
Where project is the name of your Heroku project (the same as the project.heroku.com subdomain). Once you've done so, you can use the heroku xxxx commands, and can push to Heroku as usual via git push heroku master.
If you were wanting to link a new project with Heroku, you'd simply run:
git init
git add --all
git commit -m 'init'
heroku create
git push heroku master
Notice above that you simply manage your commits like normal with Git and can still push to git. Heroku simply takes your commits and deploys them the Heroku.
$ heroku run bash
Heroku incorporates the concept of Dynos which, while useful, are a major reason to move off of Heroku once your application has matured. That said, we are currently using Heroku so it's best we understand them.
The introduction for Dynos provided by Heroku is informative and can (should) be read here, but again, Ill synthesize some of the immediately interesting bits.
According to Heroku, a dyno is:
[...] a lightweight container running a single user-specified command. You can think of it as a virtualized Unix container—it can run any command available in its default environment (what we supply in the Cedar stack) combined with your app’s slug (which will be based on your code and its dependencies). The commands run within dynos include web processes, worker processes (such as timed jobs and queuing systems), and any process types declared in the app’s Procfile. Admin and maintenance commands can also be run in one-off dynos.
A single dyno can serve thousands of requests per second, but performance depends greatly on the language and framework you use.
Luckily, we have decided to use Node for our current backend, RulingClass. Single-threaded, non-concurrent web frameworks like Rails can process one request at a time, for an app that takes 100ms on average to process each request, this translates to about 10 requests per second per dyno... the fact that Node is multi-threaded (well not really but at least it's non-blocking) means we get a lot more bang for our buck from a single Dyno.
And here is the crux of it: For each application, Heroku provides 750 free dyno-hours. Running your app at 2 dynos would exceed this free, monthly allowance, therefore we get 1 free Dyno.
Right now our Procfile declares one process called web with web: node app.js. This is the command needed to run our application and it declares that this process type will be attached to the HTTP routing stack of Heroku and will recieve web traffic when deployed.
However, any Dyno will sleep after 1 hour of inactivity. If your app has only a single web dyno running, that web dyno will sleep - irrespective of the number of worker dynos. You have to have more than one web dyno to prevent web dynos from sleeping. Worker dynos do not sleep. This is fine for development though, because when you access the app in your web browser or by some other means of sending an HTTP request, the router processing your request will signal the dyno manager to unidle (or “wake up”) your dyno to run the web process type.