To pluginify or to not pluginify?

[miguelcobain]

Today this tweet was posted on the official account of @hapijs:

Pro tip: everything you do should be in a plugin. Working directly on the server is great for learning, but real apps should use plugins.

It's not the first time I've seen this in the Hapi.js community. However one of my main concerns was exactly one of the replies from @kanongil:

@hapijs True. I have always felt that “plugin” is a misnomer for what you should actually do with it.

The docs state that:

hapi has an extensive and powerful plugin system that allows you to very easily break your application up into isolated pieces of business logic, and reusable utilities.

Indeed, not just "reusable utilities", but also "isolated pieces of business logic". At the end of the day it's just a nomenclature concern/opinion. I'm sure that many developers are used to the term "plugin" as being a 3rd party pluggable code like libraries, for instance. I'm not really comfortable with defining my business logic and models and external utilities both as plugins. But I can live with that.

I would like to raise here a discussion on the advantages of defining plugins over a more traditional project structure like this, for example: https://github.com/miguelcobain/hapi-boilerplate

cc @ruiquelhas

[AdriVanHoudt]

The problem with that boilerplate is something I'm experiencing now. When having many entities the controllers and models folder quickly becomes massive. You can compare to n°1 of https://www.airpair.com/angularjs/posts/top-10-mistakes-angularjs-developers-make For the plugin system. I've not used to many plugins but everything that is in a plugin now is awesome. I can manage it independently and test it independently.

[miguelcobain]

You mean to group by feature rather than type. I come from an Ember background, but the concepts still apply. We call it pod structure: http://www.ember-cli.com/#pod-structure

But still, we can use pod structure without plugins, right?

[geek]

@miguelcobain plugins are powerful for distributed teams too, especially when combined with npm.

[ruiquelhas]

@miguelcobain as I told you that time, I look at this, and as @geek also says, as way to better manage large projects and develop small modules in isolation within small or large teams. We can maintain and test them without any overhead.

I also like the idea of having a plugin representing a small service which might be an entity (as suggested in Twitter) or anything else you believe should be part of that service. It's definitely one of my favourite features on hapi.

[hueniverse]

Note that the term plugin is only in the docs. In hapi, you use server.register() and all it looks for is a register() method exported. Call it whatever makes more sense to you. If someone has a great idea for a name, just do a PR on the docs...

[miguelcobain]

Good point, @hueniverse. I guess I got biased by the docs.

I think the name "module" is generic and familiar enough for this concept.

[briandela]

Is there a good example of an app using plugins to group related functionality together (e.g. routing, handlers, etc.)? I think at some point https://github.com/npm/newww was using plugins for their facets (@rockbot, am I remembering correctly?) but it looks like it's not doing that at the moment and has it's routing in a single place, with related handlers broken out into facets but these are not plugins.

[ruiquelhas]

I guess they are still using it for some services.

[matthewhadley]

Are views (templates) also supposed to be encapsulated in plugins like routes and handlers? It seems like it's not possible to have hapi be aware of the location of multiple template directories in this way. I've resolved this by having a build job that symlinks plugins/foo/templates to templates/foo but would be interested to hear what other folks do.

[hueniverse]

@diffsky there is some issue with how view engines are shared right now. Basically, the engine owns the templates and when added in a plugin, it goes into the plugin's realm and only available there. I am still sorting out the open issue on this.

[matthewhadley]

@hueniverse have you had time to look at the plugins/templates approach? Is there an open issue already that I can track thoughts/progress?

[hueniverse]

@diffsky This is the issue I mentioned: https://github.com/hapijs/hapi/issues/2278

[mwawrusch]

Just to add my 2 cents to the original question. A boilerplate like this gets unmanageable very fast, and once you have more than one developer and actual production system it ends up being a nightmare. After working with hapi since the very first version in quite a few production versions we split by feature and cross functionality. Our plugin hierarchy: ..-backend-store-test-helpers ..-backend-store-core-schemas ..-backend-store-.. features go here, like ^^^^ all this is a database abstraction then we have business logic layers, including search and activity streams on top of that we have routes packaged by functionality in pugins, for example routes for /stores

A key aspect is testability and understandability. An external developer should be able to write tests and understand a plugin within a few minutes, versus getting lost in thousands of tests when writing monolithic code. Also testing gets much cleaner the more of a 'black box' you have.