Run CouchDB database on server instead of externally

[AdamVig]

CouchDB is currently hosted for free on CloudAnt.

Switching over to the actual server would allow for more control over the database configuration, faster data retrieval/storage, and higher security.

(Migrated from adamvig/adamvigdata/#49)

[AdamVig]

Note: this is not an issue related to the GoCo API, but solving the unrelated issue may reveal some design flaws in the API because it has only ever been tested with a remotely hosted CouchDB.

The production database and the testing database should be separate. Previously, they were the same, which is not a good practice. A separate testing database allows for destructive changes that would have to be quickly undone in the production database, among other benefits.

The testing database should be a separate database on the same instance as the production database, to allow for easy replication and simplicity of configuration (only have to supply one URL).

[AdamVig]

A simple solution:

1. Host the production CouchDB instance on the same server as the API. Use localhost:5984 as the URL in vars.db on the server.
2. Continuously replicate the production databases to Cloudant as an offsite backup. Since the replications are outbound, this does not require exposing the database publicly.
3. Create secondary databases on Cloudant with a prefix such as dev-. Use yourinstance.cloudant.com as the URL in vars.db on your development machines. These will be clean, non-production databases that can be easily populated with data from the production databases.

This brings out a design flaw: the vars.js file only has places for one database name, though a CouchDB instance can have several databases on it.

[AdamVig]

Alternative to steps 2 and 3 in the previous comment:

1. Replicate databases from the production CouchDB instance to backup- prefixed databases on the development CouchDB instance.
2. On the development CouchDB instance, create databases with the same names as the production databases.

Since the backup databases on the development instance will be read-only, it makes since to add backup- to their names to prevent confusion. This allows the actual names of the databases to be used on the development instance, which creates consistency between the development and production environments. With the same database names, only the URL has to be configured differently between development and production (though the database names should also be configurable).

[AdamVig]

I made the change on the infrastructure running an instance of this API and it works well. Any further changes will be bug fixes.