tower-resource

Data models that can be stored in any database or remote service using adapters.

Tower Resource

Data models that can be stored in any database or remote service using adapters.

node:

$ npm install tower-resource

browser:

$ component install tower/resource
var resource = require('tower-resource');
resource('post')
  .attr('title') // defaults to 'string' 
  .attr('body', 'text')
  .attr('published', 'boolean', false);
resource('user')
  .attr('email')
    .validate('presence')
    .validate('isEmail')
    .validate('emailProvider', { in: [ 'gmail.com' ] }) // some hypothetical one 
  .attr('username')
    .validator(function(val){
      return !!val.match(/[a-zA-Z]/);
    });

There are two DSL methods for validation.

  1. validate: for using predefined validations (see tower-validator), purely to clean up the API.
  2. validator: for defining custom validator functions right inline. If you want to reuse your custom validator function across resources, just move the function into tower-validator.
resource('post')
  .where('published').eq(true)
  .all(function(errposts){
 
  });

See tower-query for the entire syntax. The where method just delegates to a Query instance. You can also access the query object directly (it just adds .select(resourceName) for you):

resource('post').query().sort('title', -1).all();

There are 4 main actions for resources (which are just delegated to query().action(name):

  • create
  • all
  • update
  • remove
resource('post').create();
resource('post').all();
resource('post').update({ published: true });
resource('post').remove();

Under the hood, when you execute one of these actions, they get handled by a database-/service-specific adapter (mongodb, cassandra, facebook, etc.). Those adapters can perform optimizations such as streaming query results back.

MIT