Learning Ember.js: Playing with Fieldbook API

Published in

The Backlog by Ecaresoft

3 min readFeb 7, 2016

Few weeks ago I found Fieldbook service and wanted to play with it while learning Ember.js. My first approach was a good ol’ AJAX approach, then I found out about Ember Data

Update May 2016
A follow up article is up: Creating an Ember Data Addon for Airtable API

Sources

Code: https://github.com/benoror/fieldbook-app
Spreadsheet: https://fieldbook.com/books/56ad5a1a0dc76e03001d7ac3

Long Story

Recently I started learning Ember.js and couldn’t wait to get my hands dirty and make something cool with it.

Also I’d been watching closely a new DBaaS startup called Fieldbook, which aims to ease database creation by editing Excel-like spreadsheets in the cloud (MSAccess-esque).

Fieldbook is the fastest and easiest way to create custom information tools. It’s as easy to get started with as a spreadsheet, but gives you all the power of a database-driven business application.

However it’s super-killer feature is the JSON API provided on top of it:

First attempt: ember-ajax

After quickly putting together an spreadsheet based on a template by Fieldbook I read Ember’s official guide and followed a traditional learning curve. First by installing the standard toolset (ember-cli, Ember Inspector, etc) and then scaffolding a new app along with some routes & templates:

Instant Rails Deja Vu

Afterwards my initial plan was to probe the API endpoints using jQuery’s $.ajax, but then I stumbled upon the awesome ember addons ecosystem, and ember-ajax seemed like the obvious choice from a newcomer standpoint.

I quickly learned the ember-way, so I extended the service to inject Fieldbook’s API specific stuff (host, credentials, etc) and consumed it in my routes:

As soon as I needed more complex interaction with the API, like using query parameters, my code got bloated pretty quickly:

I felt it was time to throw a good abstraction to deal with this…

Second try: Meet Ember Data

Coming from AngularJS I knew about the awesome ngResource module, therefore I was glad to learn about Ember’s counterpart to deal with data services (and with better documentation too!). By following convention over configuration it was rather straightforward to refactor my code to make use of such abstraction layer.

First I created data models for my resources:

Then I found out that Ember Data is very engaged with JSON API, as it internally uses a very closely resemblance of the spec itself, so I learned about Adapters and how I could discard my previous ember-ajax service in favor of extending individual & application-wide JSONAPIAdapter’s to achieve the same functionality:

Also overriding Serializers to match the expected JSON structure:

This vastly simplified my routes: