Readers' Questions: "What are the benefits of using Ember Data over Ajax? "

Hello once again to Readers’ Questions, presented by the folks at The Ember Times :newspaper:with a little help from the Ember Core Team and friends :sparkles:

Today I’ll be answering a question by Darren:

What are the benefits of using Ember Data over POJO/Ajax?

Ember Data is an Ember addon which helps you with creating requests, normalising and serialising responses from and to your backend and efficiently managing a local cache of data. It is an Object Relational Mapping (ORM) for your Ember app and if you’re familiar with e.g. Rails, it might remind you a lot of the way ActiveRecord works. Ember Data provides another layer of abstraction for the interaction with your backend or third-party APIs.

First, using Ember Data is helpful with refactoring your application in the future, in case that the format of your API response changes substantially, e.g. by switching from an OpenAPI REST format to one defined by the JSON:API spec. Using Ember Data there is no need to rewrite big parts of the application to accommodate the new API format; instead all essential changes are restricted to your app’s adapter and serialiser layer, leaving model definitions and invocations of request functions unchanged.

Second, Ember Data as an abstraction layer enforces a clear separation of concerns between the UI and data layer in your application. This makes your app’s code base easier to manage and scale. Relying on a conventional data library like Ember Data also helps developers of the project with navigating the code base and helps with the on-boarding of new developers on the project, who - already equipped with previous Ember Data experience or after learning more about its conventions - are able to start building new features without requiring project-specific knowledge.

Third, building your own data layer is hard. What might not be obvious at first when starting out building a small, minimal viable product that has to interact with a backend, becomes more apparent, once the application scales and more nuanced data requirements emerge. As you continue building your app, you might run into questions, such as: How do you update the relationships of a resource that you are modifying? How do you ensure that data that has already been fetched from the API is not unnecessarily re-fetched to reduce the amount of requests to the server efficiently? A dedicated data library like Ember Data provides you built-in solutions for many different data management problems in a mid-sized to large application out of the box, including

  • Data caching using the store service. If you’ve fetched a resource from your API, the store will automatically cache the related data for the lifetime of your app and return data directly from there if another part of your application later on requests for the same piece of data. This saves time in rendering your UI and might even save you additional requests to your backend (if you explicitly tell Ember Data to do so). To learn more about data caching in Ember Data, be sure to check out this great example in the Ember Data Guides and read more about its benefits here.

  • Easy access to community-maintained adapter solutions for different API formats. Read also more about the benefits of exchangeable data adapters here.

  • A descriptive API for loading records with and without associated models. Ember Data provides conventions for configuring models and loading exactly these parts of records from your API that you currently need.

  • Out-of-the-box validation error handling through models. If your server returns errors on e.g. saving a new record, those are automatically reflected on your Ember Data records. You can read more about Ember Data’s built-in validation errors here.

Last but not least, it is important to mention that even though Ember Data is installed into each Ember app that is newly created using Ember CLI by default, it is not mandatory to use Ember Data in your Ember app. Besides writing your own custom data management tools tailored for your application, you may also benefit from the community’s efforts to make Ember interoperable with all kinds of APIs and data layers. Ember Apollo Client and Ember Redux are just two examples of excellent, popular and well-maintained data library alternatives to Ember Data. You can find many other top community addons on Ember Observer.

Wanna learn more about Ember Data? Be sure to read the improved, official Ember Data Guides, to check out this stellar intro into building a CRUD app using Ember Data and to join the discussions on the Ember Data Discord channel.

This answer was published in Issue #87 of The Ember Times. Many thanks go to both @CodingItWrong and @runspired for reviewing this week’s Readers’ Question✨

Last but not least, don’t forget to subscribe to the newsletter to get new Readers’ Questions and other development news right to your inbox. You can also submit your own questions! You will find a link at the bottom of the newsletter.

See you in the next issue! :sparkling_heart:


After years of using ember-data, I like to ask the opposite question: What would be the advantage of not using ember-data? Common answers I get:

  1. There is assumption XY about the API in ember-data and I have different API.
    • Great news then! ember-data comes with JSON-API, REST and dummy adapter. All of them you can also customise via adapters - the stuff that creates URLs and requests, or customise them via serializers the stuff that handles the payload itself.
  2. Yeah, but isn’t it easier to start from scratch if I have to modify things?
    • No.
    • APIs are hard. If you think they are not stop reading, try to build a non-trivial app, and come back here once you hit some roadblock you did not anticipate at the start. Out of the box you will get so much that is mentioned in the original post.
  3. I think I can create completely different and better API for my use case, so even re-using the dummy adapter won’t make sense.
    • Great, go ahead. The technologies chosen by ember-data don’t and can’t do 100% perfect job in all cases. But the truth is that there is a lot of thought from a lot of very smart people. So the solutions even though they might seem like an overkill at start, they are actually made with intention and some plan.
  4. ember-data default JSON-API adapter is too talkative. I don’t want to build such a verbose API. What about the network traffic?
    • gzip your HTTP requests. Any image on your page will be most likely bigger than most JSON-API requests / responses.
    • There is a JSON-API library for pretty much every major language out there, just use it.
    • (brag alert) Personally I use ruby + rails + jsonapi-resources in my biggest projects. They are way beyond trivial. The size of the API code? Next to nothing. The library does all the heavy-lifting.
  5. Any other reasons?
    • Testing. Trust me on this one. Mock HTTP endpoints, mass generate test data, randomise test data, etc. All this is hard. Use ember-data you will get most of this pretty much for free with ember-cli-mirage.
    • Community. Have a specific problem with your API? Because you are using ember-data you have common language so that you can easily ask people around. Create testing apps (ember-twiddle). And look up questions on stack-overflow.