I’ve been working with Ember and Firebase, trying to forgo any but the most skeleton server-side code. It’s very common that Ember apps use computed properties and observers to modify properties in a running app, but I started to wonder about persistent properties being handled in a similarly behind-the-curtain manner.
Without server-side code to implement the equivalent of database triggers, it would seem that that role falls to the client code. Say, for example, that some change occurs to a model that is being observed by another model. What if the effects of that observation aren’t merely transient to the session but need to persist. Is it crazy to consider allowing a model to essentially save itself when it detects the right conditions (and modifies some of its properties accordingly)?
On the one hand, this runs counter to expectations, but on the other hand, so do of things with Ember and Firebase (in a good way), and it does seem to separate concerns in a believable way.
Thoughts?