Database API

[jonwinton]

Problem

Right now Amphora floats in a nebulous area in regards to which database to use. The approach has been to allow any key/value store via a levelup, but this approach creates more work for an implementation to write code around its db implementation and makes it harder for the platform to implement new features because every implementation could drastically diverge.

Goal

One primary goal exists: to define a consistent API for how Amphora communicates with a DB. This would have the following benefits:

1. Any db solution could be developed as long as it abides by this API
2. Opinionated caching strategies can be developed to increase performance

API (This will be updated as development progresses)

Registration

Register the DB connector with Amphora at instantiation time with the storage property

return amphora({
      app,
      renderers: {
        html: amphoraHtml,
        default: 'html'
      },
      providers: ['apikey'],
      sessionStore: redisStore,
      plugins: [...],
      storage: <StorageModule>
    });

Storage API

The value of storage should be an object who exports the following functions:

• Default Function: connects to the database you specify, will be called by Amphora at startup time
• get: receives the uri of a Clay data structure and expects Promise which resolves a JSON object in return
• put: receives two arguments (key and value) and expects a Promise in return
• del: receives the uri of a Clay data structure and expects a Promise in return
• batch: receives an array of objects with key and value properties, expects a Promise in return
• createReadStream: receives a set of options and expects a read stream in return who will output id strings of objects from Clay (TKTKTKTK Make this better)

Deliverables

1. A refactored Amphora API to use a storage module
2. A storage module using Postgres for storage and Redis for caching (more details will be outlined in said package)