I wonder whether anyone in the Ember community has experience with the combined use of Ember data and CQRS (command query responsibility segregation)?
Our main problem is how to separate command API calls (e.g. “AttendAppointment” POST command) and query API calls (e.g. GET “Appointment”) when used in combination with Ember data.
thx Marc
I haven’t tried it myself, but I believe I am familiar enough with both CQRS and Ember Data to address your question.
Ember Data, while it is very extensible, has some assumptions baked in that make it a poor choice for an event sourcing architecture. The “adapter” abstraction is designed around a mutable data gateway, with methods like createRecord(), updateRecord(), and deleteRecord(). You can’t really use Ember Data without using the adapter abstraction.
Furthermore, I find the “store” abstraction is a mismatch with event sourcing. The store is very “place” oriented, where records are identified by ID.
For a CQRS application, I think a better data model would be an immutable persistent data structure, where each event returns a new root node.
With that in mind, let’s turn to Ember proper. I think that this, too, is a bad fit for CQRS. Ember’s “two-way data binding” design encourages (requires?) mutable state. CQRS separates query from commands by definition, but two-way data binding makes command and query two sides of the same coin.
So my conclusion is that, unfortunately, Ember Data’s design and Ember’s two-way data binding feature makes Ember a poor choice for CQRS architectures.
Thanks for your response Sam. We start working on a number of spikes (with Ember data and without Ember data) and hope to find a solution that fits with both CQRS principles and Ember as front-end framework. I will post our findings as soon as possible.
I’d love to know if you’ve figured out a good way to use both these together. I’m just starting an application and I"m starting to doubt ember will be the way to go. We’ve thought about only using it for templating and not for CRUD commands.
I think you should have different controllers, models and APIs for Projections and Events. This way, you can still benefit from Ember/Handlebars bindings by providing to Projections the expected mutable state.
Projections APIs would only need GET operations (initialize the event store and stream all events in given aggregate to make a new ‘entity-state’ projection) and Events would need GET (useful if you want to separate projection from event storing) and POST operations.
In your example, AppointmentState may be a projection of given AppointmentAggregate in certain time and date.
AttendAppointment may be an Event, backed by another API, that just need to push events to the AppointmentAggregate event store for further projection.
So guys, did anyone achieved success in your implementations ? Or maybe ember-data doesn’t best tool to building a task-based UI with ember. Any help?
I am currently in a R&D phase at my company where we are looking into a non-CRUD / more task based approach in Ember applications. You can read an initial post about what triggered all this.
I can’t promise anything, but expect a follow up with my findings in about a week. If you want, I can keep you in the loop. Just tell me how I should reach out 