How to use Ember Data inside of a Services Oriented Architecture?

Ember Data
1

Hi,

First of all, I must say that I am thoroughly impressed with Ember JS and definitely plan to use it. Ember Data is very impressive as well, but I do have some issues in my mind that I need to iron out before using Ember Data.

I come from a java background and have transitioned from Java EJB to Java, Spring, Hibernate to Grails. The typical MVC Architecture that I’m used to is:

  • View and View Model Layer – HTML, Javascript, JQuery and JSON objects as the View Model
  • Javascript Controller Layer – Javascript AJAX with jQuery
  • Controller Layer – Grails Controller
  • Service Layer – Grails Service
  • DAO and Model Layer – GORM mapped to RDBMS

This is an architecture that:

  1. Keeps my Business Logic secure on the Server Side
  2. Allows me to expose my Business Logic as web Services to other UI Apps
  3. allows me to rewrite my UI or my back end without one impacting the other.
  4. Keeps my UI JSON Model separate from my Back End Domain Model so that my views are not tied to my Domain Model and don’t have to conform to it.

I see the Ember JS core package to nicely fit into my View Layer to help me modularize and organize my View Layer properly, it essentially gives me a Struts MVC like layer for my View Model, Javascript Controller and HTML Views and I definitely plan to use it.

I’m a bit confused about if and if so where Ember Data could fit in for me. Looking at Ember Data, it appears to me that:

  1. It is definitely an amazingly written framework, but a bit unconventional for me in terms of architecture.
  2. It seems that the Ember Data Model Objects seem to be mapped directly to my Domain Model. There is no concept of a UI Model. Hence the UI Model is tightly coupled to the Domain Model.
  3. It appears that Ember Data IS my business logic layer and it is calling persistence operations. The back end basically consists of domain objects related to each other accessible over REST.

I’m a bit uneasy with this architecture because:

  1. The application’s domain model and business logic is on the client side controlled by a client side transaction layer.
    a. The client side transaction layer is not really in-sync with the back end transaction layer in cases of rollbacks.
    b. I see this as a big security risk in terms of exposing your Data Model and Business logic in the client side.
    c. Also it breaks SOA and doesn’t allow me to expose my service layer to other web apps using SOAP or REST since the biz logic is in javascript.

  2. If you have a back end sequence like so that needs to all take place in 1 transaction:
    a. Create Sale → Create A Sale Record

    b. Create Line Item records for each of the Sale Line Items

    c. associate each Line Item to the Product

    d. Associate each Line Item to the Sale Record

    e. then for each Product for each Line Item, decrease the inventory quantity by the line item quantity.

How would this work through Ember Data? It seems that Ember Data is sending saves for each Model object separately and this entire sequence of logic would live in the javascript layer? 3. If you have a front end UI that has a UI with totally different associations from the back end structure, how would this work with Ember Data? 4. If I want to keep my architecture as is and use Ember Data for my UI Model/DTO (Data Transfer Object) layer rather than my direct Domain Model mapped and biz logic layer how would this work?

In this case, I was wondering if someone could help me understand:

  1. Is it possible for me to use Ember Data in my case and still keep my Services Oriented Architecture?
  2. Am I missing something or not understanding something correctly?
  3. If the answer to 1 above is yes then what is the best way for me to use Ember Data?

I really like Ember and would like to use Ember Data. I would really appreciate if somebody could help me out with my questions above.

Thanks,

Amarish

1 Like
2

I’ve only been using ember and ember data for a month but I came from a service oriented architecture background so I thought I would throw in my experience.

Is it possible for me to use Ember Data in my case and still keep my Services Oriented Architecture?

I would say yes it is technically possible but probably not terribly useful. Others may disagree with me but my experience of ember data has been that if you don’t do it the way ember data expects then you’re going to get to know ember data’s code base / architecture a lot more intimately. Whilst this can be a fun and interesting process it’s also fairly time consuming removing a lot of the benefits of using something like ember data.

Am I missing something or not understanding something correctly?

If you wish to use ember data I would strongly recommend you read up some more on restful architecture, it will answer your questions on security, batching, side effects, reuse, business logic, etc etc. Actually just read about restful architecture anyways, it’s interesting and you can’t help but encounter it if you use anyones api but your own. It’s a totally viable, secure, sane way of doing things that has some advantages and disadvantages in relation to service oriented and there are plenty of opinionated people smarter than I who have written extensively on the subject.

If you like service oriented you can still use ember, just patch in your stuff in the router model: function.

3

Thanks for your response. I appreciate you putting in the time to answer my query.

I see where you’re coming from, but I feel like I still need more explanation. I have used RESTful architecture in the past and still use it today in many cases and I’m definitely a fan of it. But I feel like the question I’m asking isn’t really REST vs SOAP. I think you can have RESTFul architecture where the UI still gets access to the UI Model only and not the domain model and the RESTful URLs it calls are biz logic services and not direct Domain Model creations and Updates.

In fact, rather than the question being about REST, I feel like the actual main issue that I have is that I feel like in order for me to really properly use Ember Data, it seems like I need to:

  1. Expose my domain model into the client side
  2. Have business logic on the client side
  3. I’m not sure how it can be transactional from a database stand point. You can roll back your client side data, but this will not automatically roll back the server side.
  4. I don’t think that you can expose these chunks of business logic to other web apps as they are not living on the server
  5. It seems very insecure to have a .js file with all your business logic that somebody can read. Also, what’s to stop somebody from fiddling with this by using the javascript console in their browser to inspect these Ember Data Data Model objects, change their contents and simply call a .createRecord or .deleteRecord on them?
  6. The case I mentioned about the Sale use case where in 1 transactional service call you create a Sale record, Create sale line items and associate them to this sale as well as update the inventory of products sold, and this service call needs to be able to rollback from a db perspective without having to do anything extra (which it does when you use basic server side features like the transaction manager that comes built in with Spring Framework/Grails/EJB). I don’t really understand how one is supposed to achieve this if each of these individual Domain objects are mapped to Ember Data Model objects.

Again, please understand that I do not in any way mean to undermine Ember Data. Looking at the library and what it accomplishes, I know that it takes extreme brain power to accomplish this especially through a javascript library. It’s just that I want to understand it with respect to my above 6 points.

Can somebody please respond and explain to me if there is a better way for me to look at the above 6 points and if I’m missing something?

Amarish

4

I think you may find this article interesting: http://adequate.io/building-an-internal-ember-cli-ecoystem

1 Like
5

I can maybe speak to a couple of these. Yes, almost all of your business logic lives on the client, and uses servers primarily for data access. You should still be doing server side validation, and enforce your business rules. If a user needs a certain role type to delete something, your data service should enforce that. If a user wants to call ember methods directly, they should have the same rights as they would using the interface.

As far as security and being able to see your models and logic, I think you can borrow the argument for open source software: knowing that everything is exposed makes you design more secure apps because you can never rely on obfuscation to give you a false sense of security.

1 Like
6

Sorry away winter camping.

I’m not sure why you see ember data being so distinctly different from restful in general. In ember data is a pretty pure implementation of restful architecture. Perhaps you can describe the reasons you think ember-data is restricting you beyond being restful.

In terms of your questions you may wish to investigate batching and or side effects in a restful architecture.