Support in-memory storage

smashwilson commented 9 years ago

Local builds shouldn't need to use Cloud Files containers or a MongoDB instance just to perform a transient render. This introduces a STORAGE configuration parameter that allows storage operations to delegate to a "remote" implementation, that actually reaches Cloud Files, Mongo, and so on, or a "memory" one that just uses in-memory data structures.

[x] Add the STORAGE configuration parameter.
[x] Make the RACKSPACE_ and MONGODB_URL parameters optionally if storage isn't "remote".
[x] Initialize storage instead of the remote connection.
[x] Rewrite connection call sites to use the current storage, instead.
[x] Update unit tests to use the in-memory storage driver.
[x] Format with obama because it's standard JS + semicolons and we can yell at @rgbkrk if we don't like something.
[x] Update docker-compose.yml to include the additional parameter.
[ ] Create some integration tests to verify that RemoteStorage isn't broken.

smashwilson commented 9 years ago

:boom: Tests are now green again :+1:

I still need to put RemoteStorage through its paces, though, since the tests all use MemoryStorage.

smashwilson commented 9 years ago

:shipit:

deconst / content-service

Support in-memory storage #46