Anyone using JSON-API + Ember Data in production?

Ember Data
1

The official JSON API spec seems to make a good case, and lists Ember Data as ‘one of the original exemplar’ implementations, but all I can find in the wild is this very basic adapter that some kind person has started:

https://github.com/daliwali/ember-json-api

Is there anything better or more complete that I’m missing, and are any of you going down this road?

2 Likes
2

Can’t say I’m using it in production (yet), but the vanilla RESTAdapter that comes with Ember-Data has worked marvels with my JSON API thus far. Are you having any trouble in particular?

3

I was talking specifically about the JSON-API spec as outlined here, rather than just an API that communicates via arbitrary JSON - you’ll find that the RESTAdapter won’t work out of the box.

4

We’re a few weeks away from full-blown production, but we do have customers using our product (maybe 20 users), and we use the JSON API. I’m not using Ember-Data though, I’m using an alternative that I wrote for our product. (I haven’t really ‘released’ it yet, as it still needs polish, but here it is). We’ve been using both to power our app since February, and we’ve had customers using it since March. I personally think the JSON API is great. It’s probably very similar to what you would design, but it has dumb ideas weeded out by the community. :wink:

A small bit of advice though: the JSON API is changing quickly, so make sure you keep up with it. The changes aren’t big, so if you keep up with them (maybe every 2 weeks), you’ll have a better API for it.

Also, if you’re worried about the adapter: don’t be. Adapters are really easy to implement (maybe 2 hours), and chances are you’ll have to customize yours anyway. Take a look at the one I wrote to see how simple it can be if you follow the spec.

3 Likes
5

Using Ember-Data beta 7 here and we have one project that is close to being production ready (you can check it out here: http://12foot6.artificial.io/). We are using Laravel as the backend using https://github.com/rtablada/eloquent-ember and the ActiveModelAdapter that, as of beta 7, is included in Ember-Data (I think I read somewhere that this Adapter won’t be included in the final release).

When I started using it I couldn’t find any official documentation on it and it was more by chance that I found it.

6

We’re using a Rails backend with the active_model_serializers gem (which is one of the jsonapi.org compliant libraries) and the ActiveModelAdapter on Ember’s side, and it’s working great in production.

7

This is largely my path too and works well. However, JSON API the spec itself has diverged significantly from the way ActiveModelSerializers behaves, and I’m quite sure the ActiveModelAdapter doesn’t handle properly all of the current JSON API spec.

I would follow gordon’s recommendation and write your own adapter, and or use that library he referenced.

8

Thanks folks, lots of good info.

9

We’re using Ember Data (latest beta) in production and it works well.

As others have mentioned though, the JSON API the spec has diverged from the way ActiveModelSerializers behaves. But I’m guessing at some point they’ll converge again :smile:

10

In my team we’re using Ember in production since more than half year, the current versions are:

Ember 1.5.1
Ember Data 1.0.0-beta.7+canary.b45e23ba
Handlebars 1.3.0
jQuery 1.8.3

We have 2,5 millon player in our website (a football manager game :D), you can check it just entering in www.goldenmanager.com

11

Yapp Labs is scheduled this coming week to create a well-tested Ember Data adapter for JSON API on behalf of a client.

3 Likes
12

Our work just landed upstream. https://github.com/daliwali/ember-json-api/pull/14#issuecomment-47405026 Thanks to our client Plyfe for making this possible!

2 Likes
13

Great work! Many thanks to you and Stefan.

14

I’ve been using Ember-Model based on JSON-API and I’ve also been providing a lot of feedback on the most recent JSON-API drafts.

JSON-API is undergoing a lot of change currently and a lot of effort is being put into it, however IMO the spec in its current form tries to address too many competing concerns so ends up NOT doing a great job. It also fails to address some basics, but its still a reasonable place to start from.

I’ve found some fundamental flaws/limitations and unnecessary complexity tradeoffs in JSON-API which don’t match my needs or desire for performance, simplicity and superior expressiveness. This means I’ve had to abandon conformance with it.

My issues and numerous feedback comments are on the JSON API github and relate to:

  1. Fundamental differences between APIs that can use UUID based object graphs vs typed collections with server assigned ids.
  2. Simple data types which may have links to another resource (colour+colourspace-ref), (point coordinate + colour), or (measurement+unit-ref), (time+zone-ref),
  3. Transport document vs reference document mapping issues
  4. Link templates which provide dubious value given the mismatch between transport and the imaginary/conceptual reference document.
  5. Polymorphic types

So Ive been down the road and taken a different path out of sheer pragmatism.

15

I just ported my rails-backed app to rails-json-api and oat. I had customized ActiveModelSerializers a ton, and it had become unwieldy. Oat seems fairly green but robust and easy to modify.

Overall it was a fairly painless process. I’m most happy not dealing with AMS any more. I had to extend oat to prevent circular references as I did for AMS, and it was a piece of cake in comparison.

One of the things JSON-API solved for me was the separation of the requested resource(s) from the linked resources. Especially important when you’re loading an index, you want your index to reflect the filters and sorting. (Imagine showing a author’s comments to a post, which links to its author, which has other comments as well).