search

scottwrobinson / camo

A class-based ES6 ODM for Mongo-like databases.
557 stars 81 forks source link

Modularize database clients #62

Open michaeljota opened 8 years ago

michaeljota commented 8 years ago

Modularizing database clients will result in a slimmer librery, and a easy way to write database clients plugins.

scottwrobinson commented 8 years ago

I've been thinking about this lately as well and am weighing the pros and cons.

I definitely like the thought of making it easier to write new DB client plugins (and the other benefits of modularity in general), but this also means the setup process takes a bit more work since you'd have to install both camo and camo-nedb, for example. Obviously that wouldn't be very difficult to install, but you'd be surprised at how such little things can deter new users. I'm a big fan of modules that "just work", even if that means larger module size.

Not that we have to copy what everyone else does, but it looks like many similar packages don't modularize when they have the chance (like Knex). I'd like to find out why.

I'd also like to hear some feedback from others on this as well.

Thanks for bringing this up!

minecrawler commented 8 years ago

I like the idea of modularizing camo. If ease of use is a critical point for you, why not offer an additional "lite" version. The normal version contains everything, the lite version requires additional modules. That way everyone would be able to select whatever they need. For separation of your full version into an additional lite version and modules, you could use gulp or something similar. By defining the way modules are accessed (either in the normal or the lite version) it would be possible to use separate modules from the lite and the normal version... for example I could write a wrapper for MySQL which works with camo (stupid idea, but this is just an example :) ) and it would just work no matter what the user installed

jampy commented 8 years ago

I second to @minecrawler, that would be great.

Additionally, the currently hardcoded clients also make a browser build impossible as dependencies to MongoDB and Kerberos prevent a browser-build (with Webpack, for example). See also #76 in this regard.

Furthermore, having the possibility to manually initialize NeDB (or a derivate of it) and supply the instance to camo.connect() (instead of a URL) would open many possibilities.