I like Ember a lot, But I'm Worried


#1

I like Ember a lot…

But, I’m worried about transitioning to it. I work on a data-heavy site that is ~300 jsp pages. We need to get out from under jsp and into a framework that will bring structure, separation of concerns & modern JS goodness to our messy world. :slight_smile:

Here’s what I’m afraid of: Ember data pretty much insists on APIs that are actually RESTful . Some of our APIs are, some are not. The APIs that back our simple pages return lists of items from: /api/stuff/. I can PUT to /api/stuff/33, but I can’t GET /api/stuff/33. GET for a single record returns a 503. :-/

On page load, some of our pages make 12 sequential ajax calls, sometimes munging the data in the success handler of one call before making the next.

I’m sure that if I could get the back-end devs to clean up the APIs, we could build on ember and ultimately have a much better product. But, this would be lots of work, and hard to make happen. Without APIs that are actually restful, I suspect I’m going have a very painful road ahead going with Ember & ember data.

Thoughts?


#2

You don’t have to start out with Ember Data, you can just return an AJAX call (or fetch) inside the model call. So you could start out just fetching the raw JSON and slowly transition calls to Ember Data as the API is cleaned up over time.


#3

All the benefits you describe about ember are absolutely NOT dependent on embder-data. ember-data is optional and available for ease of use when working with RESTful APIs which is the common situation most Ember apps run with. That does not mean it is required in any way.

I’ve worked on apps that were 100% ember-data free and they worked just fine and brought all those sweet benefits you described. You have choices here. If you wanted to take on the task of making custom adapters/serializers you can use ember-data with your API, you can also ignore ember-data and go for manual AJAX calls, or you can do a mix of both.


#4

@localpcguy, @sukima,

Thanks! I’ve been getting myself wrapped around the “I have to use Ember Data now” axel. Great to know that I can just wait till the API mess is under control to start using it.

Thanks again for your help!


#5

Plus you can use ember data for different, weird API. You can quite easily overwrite every adapter method that do request to backend to handle you’re specific behavior


#6

You could also start using it right now. For endpoints which are already implementing JSON:API go with the defaults. If the endpoint is already RESTful customize Adapter and Serializer to match the current implementation. If it’s not yet RESTful, you may be still able to customize the Adapter and Serializer to match it. There is not restriction preventing you, to implement a Adapter which is using POST to fetch records. If this doesn’t work out for some endpoints, you could use fetch and push the record to store manually - or if you don’t need them in store (e.g. they don’t have a relationship to any other object in store), just go with it. This would allow you a smooth transition.

Also have in mind that endpoints which do not represent entities but actions for example, fetch is mostly a better solution than fighting ember-data. Also have a look at this discussion.


#7

You can change the urls for the different request types of a model by using https://github.com/amiel/ember-data-url-templates

There is also https://github.com/mike-north/ember-api-actions for non-crud endpoints.

Or just not use ED, just using ember-fetch or ember-ajax.


#8

We tried using ember-data at first and it almost caused us to give up on ember. Just use AJAX calls with POJOs when you start out. Most of the comments I see on these forums rave about ember-data but I personally couldn’t give you a single benefit over plain ajax.


#9

When using a JSON:API standard API, Ember Data can seem like magic, and more importantly, increase dev efficiency significantly because CRUD operations “just work”.

And if you don’t have a JSON:API standard API, but you do have an API that is standardized, then while you do have to write and adapter and a serializer, that should be a one time investment. Then it should help increase dev efficiency still because it’ll again “just work”, maybe with minor alterations from endpoint to endpoint for specific issues.

Where some devs have issues with Ember Data is if there isn’t any contract in the API endpoints, and so the client side devs need to start writing a custom adapter & serializer for each endpoint. We run into this in our app sometimes because the APIs are (in general) written for mobile apps, but also consumed by Ember (we’re getting better, but a lot of “legacy” endpoints). Sometimes things work great and Ember Data saves us a lot of time. Other times that saved time is eaten up by finding/fixing bugs. However, a lot of the issues we have are likely due to not thoroughly understanding the best practices around adapters and serializers. And it sounds like there is a strong push to add better documentation around adapters and serializers.


#10

@Mofungo My team shares some of the same challenges with the apps we’re building. We have a suite of financial applications (App + Engines), where each Engine, which represents a different LoB, has a completely different api among the others, and each api is no where near JSONAPI. Also, within some of the individual apis the various endpoints can differ from one another :exploding_head:

However, we are still taking advantage of ember-data with some success - and challenges as mentioned. We use a shared addon that strictly exports the various adapters, serializers, and models. We have a base adapter/serializer (e.g. serializers/application.js) module that all other LoB apis can extend from and then do their special things while reusing the shared parts.

If you’re not interacting with an api that responds in JSONAPI format, you will be forced to dive deeper into how ember-data works and use some of the lower-level adapter/serializer methods. But I found the separation of concerns to be scalable, easily testable, and TBH you would have to put the endpoint configuration and data normalization logic somewhere.