API server and consumer

[ShishKabab]

Motivation: What kind of database you use and where it lives should be an implementation detail to be decided upon at the right time. BaaS services like Firebase requires lots of logic which would normally live on the server-side, to be placed in the client-side. This logic should be able to write before deciding on the final backend, so the full product can be tested with users before making important decisions. A rudimentary REST API for internal use just to throw data between the front- and back-end should be easy to 'plug in'.

Context: The recommended usage of Storex is to put it behind a layer containing all storage-related business logic.

export class UserStorage {
    async verifyEmail({code} : {code : string}) {
        // Use Storex to fetch activation code, mark its associated e-mail and user as active, delete the activation code
    }
}

This is the level at which a API between the client should be inserted. The client-side should be able to call verifyEmail() and not care if the underlying implementation talks with Storex client-side to work with IndexedDB, or server-side to work with MySQL.

Design: We won't generate a REST API that is to be documented and used by 3rd parties, but instead focus on the simple case of internal use where the REST API is an implementation detail the team just doesn't want to care about for the moment. So I'd propose something like this:

const userStorage = new RestConsumer({baseUrl, version, etc})
await userStorage.verifyEmail({code}) // Will send a POST request to <baseUrl>/<version>/verifyEmail with {code} as the body

Everything is just a POST request, and the first argument to every method is put in the body. Not very RESTful, I know. But this is meant as a temporary bridge to rapidly prototype, not as a nice public API. A nice public API would need a very smart configuration shared between client- and server-side to determine which method uses which HTTP method for transport, status code mapping, determining which arguments go in the body, and which in query params, etc. which is just another scenario possible for a future evolution.

On the server-side, there would be something pointing to the real UserStorage() class, that knows how to retrieve an HTTP request through the right abstraction layers, and delegate it to the real storage class.

Considerations:

• This must play nice with the unified access control definition which can be found its corresponding issue
• The implementation should be abstract enough through adapters to play nice with different client- and server-side frameworks for HTTP processing (fetch, superagent, Express, Koa, etc.)
• This must live in two seperate packages: storex-auto-api-consumer and storex-auto-api-provider
• Security!!!

[ShishKabab]

This ended up becoming two packages using GraphQL as the transport layer, which still need to be documented:
https://github.com/WorldBrain/storex-graphql-schema
https://github.com/WorldBrain/storex-graphql-client

What still needs to be done is accounting for user authentication.