5 ms·
This is great. I definitely feel like the front-end could use a more ORM-like, feature rich data layer. I generally use an ORM on the backend. When I get the
by elliotlarson 8y ago
This is great. I definitely feel like the front-end could use a more ORM-like, feature rich data layer. I generally use an ORM on the backend. When I get the data to the front-end, it's still relational in nature, and I still want similar tools for working with it (e.g. schema definition, validations, and an api that lets me query and manipulate related data). It seems like Ember Data is closest thing. I wish it could more easily be used outside of the context of Ember.
- ShishKabab 8y agoYou're free to implement an ORM on top if you feel that style of access suits you more. My mail is in the article, will endorse your package and help you implement it in a clean way if you want :)
- elliotlarson 8y agoRight... sorry. I didn't make my point very well. What I was trying to say was that this is sort of an ORM, which makes sense to me. I see a need for that on the front-end. I see your other comments about how this isn't exactly an ORM, which I see as a semantic discussion. It's ORM enough for my purposes. I bring up Ember Data because it's an example of battle tested and feature rich front-end ORM. I'm thinking it would be more popular if it wasn't tied to Ember so closely.
- ShishKabab 8y agoThank you for your feedback, I got a bit confused there :) Indeed I think it's nice to be able to mix and match pieces of existing stuff, which I think more software should do. The multi-device sync I'm designing right now will also not be coupled tightly to Storex, so you can use it easily inside existing applications.