stravid

require 'sinatra'
require 'json'

current_invoice_id = 0
invoices = {}

before do
  content_type :json
end

stravid

import numberToCurrency from '../../helpers/number-to-currency';

module('number-to-currency Handlebars Helper');

test('convert invalid input to zero', function() {
  equal('€ 0,00', numberToCurrency._rawFunction(null));
  equal('€ 0,00', numberToCurrency._rawFunction(undefined));
});

test('handle single digit input', function() {

stravid

---
- name: apply common configuration to all servers
  hosts: all
  remote_user: deployer
  sudo_user: deployer
  sudo: yes
  vars:
  - ansible_sudo_pass: secret
  tasks:
  - debug: msg={{ansible_sudo_pass}}

stravid

// Rest of the file

app.import('bower_components/momentjs/moment.js');
app.import('bower_components/pikaday/pikaday.js');
app.import('bower_components/pikaday/css/pikaday.css');

module.exports = app.toTree();

stravid

require 'rubygems'
require 'bundler/setup'
require 'rom'
require 'rom-sql'

ROM.setup(:sql, 'postgres://localhost/datsu_development')

class Players < ROM::Relation[:sql]
  register_as :players
  dataset :players

stravid

require 'rubygems'
require 'bundler/setup'
require 'rom'
require 'rom-sql'

ROM.setup(:sql, 'postgres://localhost/datsu_development')

class Players < ROM::Relation[:sql]
  register_as :players
  dataset :players

stravid

require 'rubygems'
require 'bundler/setup'
require 'rom'
require 'rom-sql'

ROM.setup(:sql, 'postgres://localhost/datsu_development')

class Players < ROM::Relation[:sql]
  register_as :players
  dataset :players

stravid

curl 'http://localhost:2300/api/players' --data-binary '{"data":{"attributes":{"name":"David"},"type":"players"}}' --compressed
{"data":null} 

stravid

import Ember from 'ember';

export default Ember.Controller.extend({
  appName:'Ember Twiddle'
});

stravid

Ruby JSON API Stack

What is this? I'm a little bugged out by all current approaches that are available to build JSON API APIs. I'm writing all this down to help me figure out what I want and how to accomplish it.

There are basically two sides, reading data and writing data. There are also a few parts of the stack that can be generalized. On the other side there are also parts where I think generalization is harmful.

Things like transforming parameters from dasherized to snake case, and serializing an object graph to JSON can be kept pretty generic. The thing I'm not so sure about on the read side is handling query parameters like included, fields, sort, filter, page and so on. For example using JSONAPI::Resources gives you the query parameter handling out of the box. On the other side I think it's impossible to deal with associations if you don't use the Active Record pattern and/or have 1:1 mapping between API resources and models.

On the write