I guess this is as much a question related to ember than an API design problem.
When you have non model data, like the count of elements by criteria on an index view or the “last time period” stats, how should it be done ?
On the API side should it be custom action on the closest controller to the data ?
A catch all non rest controller with a collection of random data ?
In ember, should it be a service or a custom model for every custom data needed?
You definitely don’t need to use Ember Data for everything. Examples of times you wouldn’t want to use Ember Data might be:
- one-off APIs where you would only have a single “record” of that type
- data where you may have many many thousands of records loaded in the client
- data that doesn’t fit the shape of a “record” e.g. query results from an analytics API where the results aren’t unique and persistent (something that you could assign a unique “id” to)
Services are generally the first thing I turn to when these sorts of things present themselves. They are great for authentication, basic status or informational data, or any state that needs to be shared across your app. That said it really depends on the context. If it makes more sense (in terms of app design) to have this data in a component or just part of one route in the model hook then by all means go with that.
I think the criteria that I’d approach this with is something like this:
- Does the data fit a “record” shape and/or is it a good fit for ember data? Yes - use ED, No - consider where it needs to be be available…
- Is it “global scope” data that will be accessed from multiple places? Yes - consider a service, No - consider a route/component
- Does it fit nicely in a route model hook? If it hooks into query params at all or can just be fetched with the model you can throw a bare AJAX call in the model hook along with the rest of your model. If not…
- Consider fetching the data from a component. Obviously you don’t want to overuse this pattern but sometimes it’s the best fit