Wondering if anyone can provide some history about Ember’s decision to default to the JSONSerializer. I know this became the default with version 2.0, and REST had been the standard before then, and that there are ways to override it in a particular application.
Really interested in understanding what drove the decision. I come from the Drupal community, where there are some challenges to creating some of the JSON structures described in the Ember docs. Talking about things like relationships and included keys here, which could be a challenge to support in a meaningful way.
From what it looks like on the outside, the goal is to make data loading ultra efficient, where models line up exactly with the keys in the JSON response and developers don’t really need to worry (too much) about data on the application level. Is this really the goal, or am I reading it wrong? Is this really what an Ember developer expects from an API, that kind of control over the structure?
Would love to hear everyone’s thoughts! Ember Data is fascinating and I am really enjoying learning more.
@rishirajdev Thank you for the link! Definitely helps with another issue I have been having.
Sorry about the title of the thread, I accidentally cut-and-paste from an issue I opened on Stack Exchange. Adjusted the title to reflect what I am really after.
Ember Data is fascinating and I am looking to gain insights into what brought the community to this point. I work with Drupal and see some of the shortcomings in that system’s approach to providing data, in comparison to what I see in the docs.
But let me ask one of the things I am really curious about. What really makes for a good API for an Ember application? How often do you actually get a well-structured JSON document with all the keys needed for things like the JSONSerializer to act without a custom serializer?
Ember try follow some kind of standard to make back-end agnostic. The currently ember version has the default adapter accept json-api standard http://jsonapi.org/
Django, Ruby on Rails already have good integration with default ember data adapters.
I actually returned to REST again. What really bothers me is that json api doesn’t have a convention on how to send multiple records to the server in one request. So the EmbededRecordsMixin just doesn’t work anymore. And an even bigger frustration is that some add-on I’d like to use, like ember-data-model-fragments, just don’t work.
Welcome @techsoldaten! Re your questions, a few thoughts. I found this podcast provided some background ( https://changelog.com/189/ ). In essence I would say the goal with JSON-API is to provide the ad-hoc ability to query for items (and related items) from the Ember side of things while continuing to work reasonably well in a REST API world.
As far as what makes a good API for an Ember app, JSON-API is considered the Cadillac for the things it’s good at (with saving of multiple related models to the backend being a place where folks are still experimenting). However, Ember Data’s adapters allow for working with some really, really nasty APIs as well This talk from a few years ago was what really helped the light bulb go off in my head: https://vimeo.com/101579258 Note: it’s two years old which in Ember-land is an eternity. Don’t focus on the technical details as much as the overarching ideas.
For Drupal folks, what I would suggest you do is focus on either building an Ember Data adapter add-on (there is a Wordpress one already) or look for Edward Faulkner’s JSON-API module for Drupal that is supposed to help Drupal talk JSON-API more fluently. He talked about it in his DrupalCon talk about a month ago, but not sure what has happened with it yet.
If you’ve got other questions, feel free to post them here on the forums or drop into the Ember Slack to visit with people. Look forward to seeing you around more.
This talk from a few years ago was what really helped the light bulb go off in my head: