looking at hapi repo organization within cloud services

gistfile1.txt

existing repos
==============

fxa-profile-server
/bin
  - looks like this just does instantiation, dependency injection,
    like the /server directory in the fxa-auth-server repo
  - _static.js - load local-dev-only static server
  - server.js - just load lib/server and start it, pass in the logger
  - worker.js - just load lib/server/worker and call create
/config
  - same, stuff for dev/local/prod
/coverage
/docs
/lib
  /compute
    - index.js: compute cluster used to spin up workers
    - image-cc.js: contains image resizing worker
  /db
    - db connector strategies: memory / mysql files
    - schema file (no migrations)
    - index.js loads the right db depending on env
  /img
    - img save strategies
      - several files to save images locally or on S3
  /logging
    - logging stuff, dunno if it's truly needed, i'd put it flat in the
      lib folder.
  /routes
    - routes again
  /server 
    - all the individual servers
/scripts
  - deployment scripts
/tasks
  - grunt stuff: jslint, release, jscs, test
/test


fxa-auth-server

/bin
  - contains processes / separate servers
/config
  - config for dev, stage, prod
/crypto
/db
  - put our stuff here: models? migrations? both?
  - maybe both short-term
/docs
  - use this once README gets too crazy
/routes
  - individual routes for pages
    - looks like the handlers are generally defined inline :-\
      - not a fan, this makes it hard to read the routes off quickly
/routes/static
  - serve static pages
/scripts
  - start/stop server, start/stop testing
  - awsbox stuff
/server
  - index.js: just loads server, looks like it does dependency injection:
      var Hapi = require('hapi');
      var path = require('path');
      module.exports = require('./server')(path, Hapi);
  - server.js: actually creates the Hapi server, register the packs,
    register special server events
/test
  /client
  /config
  /load
  /local
  /remote
  /bench
/tokens