search

rijs / fullstack

modern fullstack framework
242 stars 21 forks source link

ORM #4

Closed pemrouz closed 8 years ago

pemrouz commented 10 years ago

Use https://github.com/1602/jugglingdb to get the ability to talk to different databases for free.

mstade commented 10 years ago

No such thing as a free lunch. My gut feeling is that the relationship here should be inverted, and whatever persistence layer an app wants to introduce should be able to hook into ripple. You do this for the html, why not persistence as well? It keeps the API surface area small and focused, and whatever potential developer productivity savings you were hoping to get from the .db call will probably not be worth the effort and ensuing pain of supporting disparate databases; ORMs never fail to not really help.

pemrouz commented 10 years ago

Haha, that lunch actually happened to be a coincidence :). You raise a very good point re:ORM's. My only concern however, is that as an application developer, I'm going to be consistently connecting ripple to a database anyway. So it would make sense to save time for the next user having some level of re-use for the next developer that will be doing the same thing (same repo or different repo). But I generally agree with you that is how it should be architectured. As long as you implement the four basic crud functions, you can now easily extend the database adaptors.

Another reason to implement/expose your function hooks idea however, I picked up from @udidahan at mucon, is that resources ("micro-views" in his terminology) could want to connect to different databases (essentially, cohesion between micro-views and micro-services). For example, it may make more sense to load recommendations from a graph database and navigation items from a different NoSQL database. An application developer could easily differentiate and route different resources to different databases using those hooks.

Per @HunterLoftis's request, I added support for postgres, a new realtime, collaborative, simple pixel editor and the bonus of it running on heroku :)

image

mstade commented 10 years ago

For example, it may make more sense to load recommendations from a graph database and navigation items from a different NoSQL database. An application developer could easily differentiate and route different resources to different databases using those hooks.

This, right here, is exactly what I'm yammering about. There's no reason to have this be integral, when it can be solved by function composition. Cleaner separation, more flexible, yet not significantly (or any) more work for the developer. Don't fall into the trap of saying "but surely everyone will want this?" when it's not core to the problem you're trying to solve; you'll find more often than not it'll come back to bite you.

pemrouz commented 8 years ago

Needless to say, this was a bit too ambitious/silly/unnecessary. DB/MySQL adaptors deprecated in 0.6.3.