Ember Data

Ember Data is an optional library that all new Ember apps have built-in by default. It is very powerful and allows you to make use of Ember Data records and provides an own API and several methods to access the data. Although, you do not have to use EmberData, since Ember works with any type of back end, be it REST, JSON:API, GraphQL or whatever you like. We use JSON:API and our adapters extend on the respective class. Ember Data supports us with regular CRUD functionality.

Adapters

Adapters allow Ember to be flexible with the backend, since you can configure them to work with any backend you might need to use. Ember has some preconfigured built-in adapters as well. The default backend in Ember is JSON:API. Thus, we have access to a standardized way of talking to the servers.

The go-to practice in Ember is to provide one store that can be accessed anywhere in the application. This store is automatically injected to routes and controllers and is accessible via this store.

Every model is an extension of the Model class and defines attributes, relationships and behavior of the data you are going to present. These models define the data type provided by the server and describes the relationships to other objects. The models themselves do not have any data, they only define the properties and behavior of the specific instances, that are called records. Records can be identified uniquely by their type and ID. Usually, the server assigns an ID when the data is first stored, yet, it is possible to generate them on the client side.

In order to communicate with the server, we need to translate Ember’s request to fetch the data into something the HTTP-server understands. We have access to adapters that provide this functionality. Since we do not want to flood the server with HTTP requests, the store caches records and can present it again, once it was loaded and had not changed since the last request. Sometimes Adapters can not return requested records at once and have to make asynchronous requests to the server. In these cases they return promises. And since the adapter has to pass promises, the store also does so. When the server finally answers the request, the adapter resolves its promise with JSON, and after that, the store resolves its promise with a record and returns it to the app. If the store has the requested record in cache already, it can simply resolve the promise with the cached record.

In Ember, you are encouraged to extend the standard adapters in order to customize them to suite the needs of your app. You might need to create a model specific adapter or override the main application’s one.

In any case the CLI helps you creating the needed files by typing

$ yarn ember g adapter application

like we did last week in order to override the default adapter. Overriding is helpful if you need to specify a namespace or define the host-URL. It is also possible to set up HTTP-request headers, e.g. to specify CORS-rules or authentication, since some APIs require them. You can even make them dynamic using ES6 getters and service injection. This is very helpful, when you want to pass the current user’s authentication information, for example. Adapters work hand in hand together with serializers.

Serializers

Serializers format the data that is sent to or received from the server. Again, the default format is JSON:API. You can, however, customize the serializers to your needs. Serializers can be generated using Ember’s CLI.