Ember.js Persistence Foundation | Hacker News Reader

Ember.js Persistence Foundation

epf.io

47 pointspie22 comments

> Epf is essentially an ORM for the web and gives you all the tools necessary to define models and synchronize with your backend.

That line should be on the front page of that website. I've spent too much time trying to decipher the bizarre diagram and trying to figure out whether it was an inside joke I wasn't getting or an actual thing.

THIS! That diagram is just ...

The diagram is horrible and doesn't really explain anything. I want to know what it is, not stare at some cryptic diagram for ten minutes.

Don't want to show off, but it seemed quite readable to me, once you notice that the arrows have numbers..

It shows many interesting details (the only API command seems to be Patch. There are two sync phases on the client, one to determine what to send to the server, one to determine what to merge upon server response). I quite like diagrams :))

What do the numbers represent?

Lifecycle of data as it changes, apparently.

Sorry about the obtuse diagram. In my little Ember.js bubble it seemed important to differentiate it from things like Ember Data. These pages will improve.

This is super cool - What method is used for continued client side updates? Websockets, polling?

The readme says it works with any "persistent backend such as a REST API or socket connection".

It looks like it tries to be backend-agnostic, and do the sync work on the client side.

I'm assuming - and this could be a bad assumption - but based on the continuing updates architecture, if client a changes model a, client b will see an update on model a. How does client b get notified of the change? Does it have some kind of fallback system ala socket.io? Is this not yet part of the project?

Backbone took a REST opinion, I imagine if you want something like you describe, they (or someone) will implement something like backbone.io.

https://github.com/scttnlsn/backbone.io

Judging by the chart on the site, it looks like each client polls the original model on the server, and infers changes by diffing it against the client's current copy.

It tries to be agnostic about this and favor any particular push method. Instead, it simply provides the primitives on the client to make these things easy (e.g. merging in new data).

Now if this works, which Ember-data doesn't (not finished I guess). This is a bigger step towards using Ember,

I've been using Ember-data for the past few months on side projects and it's getting a lot more stable. I've rarely had issues with it in the past few weeks.

Last time I used it, I think it was Revision 11, it had issues with relationships and deletions, how is it holding up now? I'd love to give it another go!

There are still issues on rev13. For example, when binding to the didCreate event after committing a model, the model.id is not defined. You would think `didCreate`, fired when a response is returned from the server, and that response includes the complete model including the ID, your client-side model would now include the ID as well. Not so! You have to do tricks like `model.addObserver('id')` to get what you need.

Ember.js is great fun, until it goes horribly wrong. On the other hand, the Ember Core team does not call it a 1.0 — and they certainly do not say Ember Data is finished. I think it's unfair to judge such early builds.

"weeks" ?? Damn... I remember when I had to choose between angularJs and other JS frameworks a few months ago. Reading your comment makes me feel really good with my choice.

I've played around with Angular quite a bit lately as well and I definitely prefer Ember. You should really try both of them out and give them both a fair chance.

Also, you don't have to use data with Ember, it's just a benefit.

Author of Epf here. We had used Ember data for over a year before creating and switching to Epf.

Epf was heavily inspired (if not directly based on) many parts of Ember Data. We felt that Ember Data provided the right level of abstraction, but fell short and created road blocks for us in certain scenarios.

Is this supposed to be a framework for collaborative editing and synchronization? I would expect a lot more examples around merge conflicts and locking if so. "Models are never locked" make this sound like it is just an abstraction for abstraction's sake, why would I use this instead of just binding DOM elements to JSON?

It's made to be a generic ODM/ORM for use on the client side with Ember.js. It's a replacement for Ember Data, which has a ton of bugs and limitations.

Reply on news.ycombinator.com