We currently have a mess in the exercism service where it is used to both communicate with the API and gather local files info.
It makes more sense that all the communication to the API is done with ember-data (currently only the tracks endpoints use ember-data) as it will take
care of serialization, errors, etc. Plus it will be easier to test and use ember-cli-mirage.
The reason I decided to initially take a more manual approach was that the API requires quite a lot of modifications to the ActiveRecord adpater/serializer
since the API URLs and responses do not follow clear conventions (they change from endpoint to endpoint) and it uses two different hostnames.
This was fine at the beginning as it allowed to iterate quickly and get a prototype working faster, but leveraging ember-data is the way forward as it will
result in a much more maintainable code
We currently have a mess in the exercism service where it is used to both communicate with the API and gather local files info.
It makes more sense that all the communication to the API is done with ember-data (currently only the tracks endpoints use ember-data) as it will take
care of serialization, errors, etc. Plus it will be easier to test and use ember-cli-mirage.
The reason I decided to initially take a more manual approach was that the API requires quite a lot of modifications to the ActiveRecord adpater/serializer
since the API URLs and responses do not follow clear conventions (they change from endpoint to endpoint) and it uses two different hostnames.
This was fine at the beginning as it allowed to iterate quickly and get a prototype working faster, but leveraging ember-data is the way forward as it will
result in a much more maintainable code