Should not be opening a database connection and exposing it?

[samhstn]

When looking around for good plugin practices I came across this gist which says that opening a database connection in a plugin and exposing it is a bad practice

and this comment: "using plugins to load a db connection is an odd pattern"

I am quite confused as to the reasoning behind why this is considered a bad practice. I don't see any reason for thinking that exposing your database connection this way should lead to any issues.

I think this module provides a really nice way to initialise your database connection in one place and then be able to cleanly make database queries anywhere in your application so I'm going to still use it.

But why are some people in the hapi community saying that it's bad to be exposing your db connection across your application?

[eliasmalik]

@shouston3

I think in general it's considered bad practice to have dependencies crossing plugin boundaries. Plugins are (ideally) meant to be fully isolated units of functionality. Removing one or more plugins from your app shouldn't break it completely. If there's some app-critical bit of setup you need to do, it should be done outside of a plugin (perhaps just as a node module).

Out of ignorance, I have consistently broken this 'rule', because I have been using plugins simply as a way to modularise the functionality of my app. I don't think this is really what they were intended for. If you find yourself using server.dependency a lot, or having to be careful about the order in which plugins are registered, I would now consider this a code smell.

This is a separate issue to whether or not you should expose a DB connection on server.app, which is what (I think) you actually are interested in, and the hapi maintainer seems to agree that this is a good/acceptable pattern, given what he's said on the issue and gist you linked.

[nelsonic]

@shouston3 thank you very much for raising this issue/question! 😍 while I respect that some people might consider putting a DB connection in a plugin to be a "no-no" as far as "Best Practice" is concerned, I haven't (personally) seen a simpler alternative which reduces the number of lines of code require-ing and "booting" a connection in each route handler and which allows me to close the connection once at the end of my tests (_instead of having to write "tare down" code in each of my tests...!_)

This plugin opens the connection to PostgreSQL once and makes that connection available anywhere in the request lifecycle so the request handler can conveniently make database queries without having to include "boilerplate connection" code in every file and without worrying about closing the connection once the query has been executed.

if those are our two "requirements" I would absolutely love to hear an alternative way of doing this without using a plugin. this way seemed like a "win-win" to me... but as always, I'm hapi to be shown the error of thinking by a more XP person...

I geniuinely don't understand why it's considered "bad" (probably because I'm not "smart" enough...), but having read many books on "patterns", "security" and "performance" and not found anything warning me that this is a "bad idea", I too am going to continue doing it this way until someone can present a convincing argument for an alternative method. 👍

@eliascodes 🥇 Crossing plugin boundaries is a "horrible idea" for most plugins. (agree 100%!)

The apps we have built with PostgreSQL (or Redis for that matter) simply don't work when the database connection fails. And instantiating the DB connection in each plugin/handler feels "unDRY" to me...

If we prefer to expose the DB connection on server.app we could add that to this plugin. However I tend to find that having the DB available on request works for most cases.

I'm definitely not an "Expert" on Hapi or Plugins, so if other more experienced people have some wisdom to share on this topic, I'd love to learn...! e.g: @mtharrison who literally wrote the book on Hapi might have some insight...? ❤️