Running Node all the way from development to production on Heroku.
Check it out at http://node-articles-nlp.herokuapp.com/.
$ brew install mongodb rabbitmq $ brew services start mongodb $ brew services start rabbitmq $ npm install
Deploying is easy - just use the Heroku Button:
If you'd rather clone locally and then deploy through the CLI, you can do that too:
git clone firstname.lastname@example.org:heroku-examples/node-articles-nlp.git cd node-articles-nlp heroku create heroku addons:add mongohq heroku addons:add cloudamqp heroku config:set NODE_ENV=production heroku config:set VIEW_CACHE=true heroku config:set THRIFTY=true git push heroku master heroku open
Environment variables are mapped to a config object in lib/config.js.
This provides reasonable defaults as well as a layer of generalization
You can locally override the defaults by adding variables to a .env file.
The app is separated into two tiers:
This enables horizontally scaling both web traffic and long-running jobs.
The default deploy configuration includes
THRIFTY=true, which starts the app in single-dyno mode to avoid charges.
THRIFTY=true, the web process handles both http requests and queued jobs.
Keep in mind that this is a specific setting for this app,
THRIFTY is not a standard Heroku configuration.
Of course, a production app should never run in a single instance or make users wait for worker processes. When you're ready to test in staging or deploy to production, you can scale beyond single-dyno mode:
heroku config:unset THRIFTY heroku ps:scale web=2 worker=2
Writing maintainable Node apps is all about separating concerns into small, well-defined modules. This barebones app has three distinct components with their own responsibilities:
The business logic is all in lib/app. This module orchestrates and provides a facade for the underlying MongoDB database and the RabbitMQ job queue.
The user-facing portion of the project lies in lib/web. This module is responsible for providing an http interface and routing requests. It shows things and relies on an App instance to do things.
The background processes run through lib/worker. This module is tiny - it just instantiates an App instance to process the job queue.