Promote k7 to Hapi's org

[thebergamo]

This is the third issue opened about this subject, but here we go!

Some points needs to be cited:

Why my module need to be in the org: Hapi have a lot of modules in the org and outside the org, each module in the org doing a good part of a development using Hapi framework, some examples are: Good, Lab, Joi, Yar, Bell. Each one of these module, have a good way to do a piece of our apis or another use with Hapi, but when your're talking about the database level, we haven't any module in the org with this domain and 90% of projects you will need to use a Database. k7 was designed to work in the Hapi's way and want to support the most used Data Mappers in Node ecosystem. Not need change your models or something to use k7 and Hapi, just plug your Data Mapper and access that in any part of your api.

What's the state of the project: Currently, I'm refactoring the code with the standards of Hapi's Guidelines and some improvements.

Need a new Lead Maintainer?: No, I'll continue developing and maintain the module, but PR are very welcomed!

Link for k7

[nlf]

sorry, but my vote is no. i think this is a subject where usage varies so widely that i'm hesitant to promote any kind of standardizing.

[mark-bradshaw]

I'm very happy to see k7 in the satellite of plugins surrounding Hapi, but I'm not convinced having it in the Hapi org is the right place. I hope this isn't discouraging to Marcos. I also have an outside project that doesn't fit inside the Hapi org. What's best for the org IMO is to keep the projects inside to the minimum necessary, and let the outside constellation of plugins and addons evolve independently.

[mtharrison]

Agree with points raised by others. This would be seen to become the official way to use a database with hapi and one of things I really like about hapi is that it's not opinionated about that at all. It tries to stay out of the way of everything not concerning HTTP and the operation of your server, with the exception of a few utilities that have been built up around hapi.

Perhaps I'm missing out on a lot, and in the minority, but I've never actually used one of these data mappers before, I generally just use the package for which ever storage system I'm using, be it node-mysql, rethinkdb or whatever. I would be concerned that newcomers to hapi immediately think they need to learn k7, mongoose or whatever to use a database, when they don't.

[cjihrig]

Sorry, but -1 from me.

[DavidTPate]

For me, I don't understand why this is needed to be tied to Hapi. Personally, I don't think it is good practice to bleed your persistence layer into your service logic so closely.

Aside from that though, I just don't see what value modules such as k7 offer as they are just shallow wrappers around the larger persistence modules like sequelize and don't seem to provide any additional abstractions.

[devinivy]

I do appreciate the value of k7 as offering a standard interface to models (given that they will often be made available in different ways using server.bind(), server.app, as a request decoration, etc. for convenience), but I don't see any particular reason for this type of module to be under the hapi umbrella. To justify that idea I had to think a lot about catbox and how caching is more fundamental to writing an HTTP server than data persistence and object-mapping in the broader sense.

I would also bring-up that I think modules under the hapi umbrella should cater to pluginized deployments where applicable. In this case if k7 were voted into the hapijs org I would ask that it perhaps be adjusted slightly to behave more like vision, where models are declarable at the plugin-level (similarly to how view managers are declared at the plugin-level).

On a personal note I think Marcos is awesome, writes high-quality hapi modules/projects, and would make for a great lead maintainer within the organization.

[hueniverse]

I think the decision about including new modules in the org should be based solely on community participation, not on endorsement. When I add a module to the org, I mostly care if others will want to participate maintaining it and if it has wide enough appeal. What I would like to see before accepting new modules is that they are actually attracting wider contributions than one lead maintainer.