Skip to content
A Heroku app for compiling Arduino sketches in the cloud
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
lib
script
sketches @ e82fc77
.gitignore
.gitmodules
.vendor_urls
Procfile
app.json
package.json
readme.md

readme.md

Arduino Compiler

An Arduino web compiler (a thin wrapper around the arduino executable)

Local dependencies

Installing

$ brew install mongodb rabbitmq
$ brew services start mongodb
$ brew services start rabbitmq
$ npm install

Running

  1. npm start
  2. http://localhost:5000

Deploying

Clone locally and then deploy through the heroku CLI:

git clone git@github.com:AllwineDesigns/arduino-compiler.git
cd arduino-compiler

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

Config

Environment variables are mapped to a config object in lib/config.js. This provides reasonable defaults as well as a layer of generalization (process.env.MONGOHQ_URL => config.mongo_url).

You can locally override the defaults by adding variables to a .env file.

Scaling

The app is separated into two tiers:

This enables horizontally scaling both web traffic and long-running jobs.

On Heroku

The default deploy configuration includes THRIFTY=true, which starts the app in single-dyno mode to avoid charges. With THRIFTY=true, the web process handles both http requests and queued jobs. Keep in mind that this is a specific setting for this app, as 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

Locally

npm start runs node-foreman, which will check the Procfile and start a single web process and a single worker process.

To test that your app behaves correctly when clustered in multiple processes, you can specify process scales to node-forman and set CONCURRENCY=4 in a local .env file.

Architecture

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:

App

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.

Web

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.

Worker

The background processes run through lib/worker. This module is tiny - it just instantiates an App instance to process the job queue.

You can’t perform that action at this time.