I started with Ember when the JSON API become the default option for Ember Data.
Now, my biggest show stopper to use Ember in bigger projects is the data layer, because I do my own backends. JSON API is so great from the point of view of Ember, but preparing a nice backend, with relationships and nested objects… can become a nightmare.
I have read some interesting threads about alternatives for the backend, but having one foot in Ember and another foot in a new learned framework seems to me like running on ice.
I am thinking about start again, but using REST.
It seems to me that relationships can be easier in the backend. And also nested objects from PostgreSQL, that I use a lot.
Nobody knows about the future, but Ember is an “opinionated framework”, so it should be great to hear an opinion Im afraid of being outdated somehow in the future Ember developement.
Hey @Nacho_B, I think it’s a good question, but I think a REST API is a perfectly good choice for a backend. Ember ships with two other adapter/serializer pairs by default (json – not to be confused with json-api, and rest) so supporting a conventional API is still dead-simple, and you can always customize your adapter and serializer to fit your needs. JSON API does provide better support for certain things like polymorphic types and more robustness around relationships and such but I don’t think it’s as much of an “outdated” thing as it is just that JSON API is more verbose and specific and therefore more powerful.
The things that are going to make your life significantly easier or harder when writing the backend aren’t as much what response format you choose but the general architecture of your API and what backend framework you use. Many backend languages and frameworks now have easy JSON API addons. My company just started using a JSON API library on top of Django Rest Framework, so with only a tiny bit of backend config and zero front-end config we can use JSON API.
As far as backend architecture, I’ve found that keeping API structure as flat and resource-centric as possible is easiest (vs “nesting” data and endpoints) but YMMV.
Anyway hope that kinda answers your question, I wouldn’t say JSON API is necessarily going to make other conventions obsolete any time soon, if ever. And additionally one of the best parts of Ember Data is how configurable it is. It’s built to support pretty much any backend you can throw at it (though some lend themselves to its conventions better than others).
Your app will live longer. I think JSON API was a good idea at the time but with GraphQL, Redux, I personally see JSON API as obsolete. A very small subset of developers use it and with the Ember community being small as it is I would not bank on getting up to date non-trivial best practices and usages.
@Nacho_B, one other thing to keep in mind is that if your application doesn’t have complex relationships between various data entities (models), you may not even need/want Ember Data. If your routes’ models are isolated – they don’t reference data from other routes – and you don’t need niceties like pagination or filtering, it might be simpler to use ember-ajax or Javascript’s builtin fetch in your model hooks to make calls to your backend. Then your backend can conform to whatever schema you’d like!
One suggestion: because REST APIs can be highly idiosyncratic and there’s no standard, you will often find yourself wondering how to tweak the adapter and/or serializer to get what you want.
In those cases, you may actually be better off using the JSONAPIAdapter and JSONAPISerializer even when your backend doesn’t conform to JSON:API, because then your job of customization is clearer. You write serializers that convert from your server API (which you understand) to JSON:API (which is thoroughly documented) as opposed to converting to whatever-the-RESTSerializer-expects (which is harder to pin down and is less expressive than JSON:API).
This can make the whole system dramatically more understandable, because you can limit yourself to knowing just two Serializer methods (normalizeResponse and serializer) and with that you can do literally anything you need.
This is a somewhat confused position. It sounds like you’re saying to pick plain REST over JSON:API because you think GraphQL will kill JSON:API.
Firstly, that doesn’t make sense, because then your advice should be to use GraphQL, not to use plain REST.
(And I think you didn’t say that because you realize that REST APIs are still everywhere and are absolutely going to continue to be for the foreseeable future, right alongside GraphQL where that makes sense.)
Second, you absolutely don’t gain longevity by hand-rolling an entire RESTful API design rather than picking up a pre-designed one for you. People seem to forget that JSON:API is just a codification of hard-won lessons by teams that had created lots of REST APIs. It’s not an alternative to making a REST API, it’s “how to make a REST API without repeating all the typical mistakes”.
@Nacho_b, when you consider how to implement your server side I think it’s important to realize that the JSON:API spec is designed to make it easy to be compliant. You only have to implement what you’re going to use.
I find the spec a huge help when implementing APIs, because it answers questions that come up naturally, and if you go with the JSON:API answers each time that happens, you don’t end up stuck in the future when you go to add some new capability.
Last thing: don’t worry about this, particularly when it comes to data layer.
There’s a very good reason ember-data is a distinct thing from ember. Lots of people are using Ember happily with no data library at all, or with GraphQL, or with ember-data.
The coupling between Ember and whatever data layer is quite loose, as it should be.
I’ve been testing things during the weekend, and I really like how Ember works whit JSON:API but I don’t like JSON:API.
There are situations when Ember is the key, but the backend can be interchangeable. For those projects I need to find and learn a JSON:API solution, easy to implement.
But to face more complex projects, where the backend is also important… I must wait until I develop a deeper understanding of how Ember Data layer works.
Following Edward’s reasoning about Ember and Ember Data architecture, decoupling backend and frontend toolbox is also a must. I foresee a lot of questions in this community
Hey, do you happen to know if ember data supports niceties like filtering and pagination? In some of my projects, I’ve actually had to avoid ember data because I needed these niceties and I didn’t think ember data supported them.
I work on an app which uses Ember + slightly customized REST adapter for the frontend, and Django + Django REST Framework for the backend, and I fully agree with @dknutsen’s thoughts.
Ember Data supports them insofar as you can pass in arbitrary options when using query(). If you use the correct options according to the JSON:API spec, namely page, filter, and sort, then you’re good to go as far as Ember is concerned. It’s really up to your backend’s implementation of JSON:API to make all this work, though.
ember-data uses json-api as the spec through which to communicate with the store. Adopting a community standard here instead of our own allows us to share terminology, concepts, and documentation more easily.
This does not mean that ember-data requires json-api
You can use any API format you wish, so long as you write a Serializer that serializes/deserializes to the proper format.
Typically you will want to implement your own serializer, and should not rely on the reference implementations that ember-data provides. If paired with one of the provided adapter implementations, this is all you need:
export default class Serializer {
constructor(createArgs) {
Object.assign(this, createArgs);
}
// must return a `json-api` document with lower case dasherized types and camelCase members
normalizeResponse(store, ModelClass, rawPayload, id, requestType) {}
// called by Adapter.createRecord and Adapter.updateRecord, but if you implement these adapter methods yourself you may build a totally different serialization API that works for you.
serializeIntoHash(hash, ModelClass, snapshot, options) {}
static create(createArgs) { return new this(createArgs); }
}
GraphQL is not a json-api killer, if anything, json-api is the much needed enhancement that GraphQL needs.
Im afraid of being outdated somehow in the future Ember developement.