search

hapipal / boilerplate

A friendly, proven starting place for your next hapi plugin or deployment
https://hapipal.com
184 stars 26 forks source link

server/plugins vs lib/plugins #35

Closed jamesdixon closed 7 years ago

jamesdixon commented 7 years ago

Hi again,

When exactly would you use server/plugins vs lib/plugins?

Thanks!

devinivy commented 7 years ago

TLDR: server/plugins/ contains plugins specific to the deployment of your application plugin contained in lib/. This plugin is assumed to possibly be part of a greater application, and potentially other deployments than server/. lib/plugins/ is concerned with plugins critical to your application plugin's features. We're big on keeping deployments and plugins separate!

This boilerplate comes in two parts (expect better documentation around this soon!). First and foremost there's lib/, which is where you will develop your application in the form of a plugin (an "application plugin"). Secondarily, there's server/ which is a standalone deployment of the plugin you've built in lib/– this is good for testing or actually deploying your plugin.

This is built in the mindset of, "perhaps my plugin (lib/) is just one of many plugins that comprise my application." This boilerplate can be used as a deployment, or just as a way to author a plugin that's a dependency of a larger application. There's an emphasis on not assuming that lib/ contains your entire application– it's just one chunk of it and the rest possibly live in other repos. For this reason we keep certain plugins out of lib/.

Plugins for swagger and a pinger live in server/plugins/– that's because they're not really essential to the functionality of the application plugin (lib/) I want to build and possibly use in another project– they are more a feature of the deployment of that application plugin. On the other hand, lib/plugins/ is where you put plugins that do add features necessary for your plugin to run. These are the additional plugins that your application plugin depends on– for example, if you needed a cookie-based auth scheme, you'd probably register hapi-auth-cookie in lib/plugins/.

The lib/plugins/ folder is also a bit special! Because lib/ is setup via haute-couture, our file-based plugin composer, when you place files in lib/plugins/ they are picked-up automatically! You would not have to write any additional code to register those plugins :)

jamesdixon commented 7 years ago

@devinivy wow! thanks for the killer explanation! Makes a ton of sense.

I love the idea of haute-couture; seems to make more of a convention over configuration approach, which I really dig. Certainly makes it much easier to get up and running.

Here's a related question: can you use haute-couture for configuring plugins that are already in the /lib/plugins directory?

jamesdixon commented 7 years ago

On a side note -- really love all of your projects. You have some really great stuff.

devinivy commented 7 years ago

Hey, thanks a bunch! :) Many of these projects are going to be more actively supported soon, and will have better documentation surrounding them.

Here's a related question: can you use haute-couture for configuring plugins that are already in the /lib/plugins directory?

Do you mean, you'd like to author more plugins within lib/plugins/, each of which also use haute-couture? Yes, that should work! In that case I'd give each plugin its own directory in lib/plugins/, and use lib/plugins/index.js to configure their registrations. Just making sure– did I understand your question correctly?

jamesdixon commented 7 years ago

Yes, that's exactly what I was asking! Thanks!