In the last two chapters, we introduced hapi, a server framework that simplifies developing servers in Node.js through a configuration-centric approach, and provides the tools needed to aid development where possible and stays out of the way when not needed.
We then looked at adding functionality to a hapi server, and looked at the tools needed to build APIs, web applications, and websites. During this, we touched on plugins, and the way in which we can use them to extend the functionality of servers.
In this chapter, we're going to look at methods and patterns for structuring an application as it grows, using plugins. This will involve taking a more in-depth look at the plugin API, so we can see what happens under the hood when we register a plugin, and how plugins can be used to break up the functionality of your server into smaller, more manageable parts.
By the end of this chapter, you will have the tools you need to grow an application codebase in hapi in a disciplined and structured manner, although it will take practice and experience for this to feel at ease when building an application. Let's get started.
The way to structure an application is sometimes ignored when initially evaluating a framework in favor of how quickly we can get a 'hello world' example working, or the ability to quickly add features. In my opinion, this is a huge mistake as this borrows time later on in an application's life cycle; this is often known as technical debt. It leads to frustration, poor developer experience, and to a lot of required refactors that often degrade code quality. Furthermore, as teams scale, poor application infrastructure leads to much slower progress—adding features, longer time in getting new developers up-to-speed, and a higher tendency to create bugs with unknown side effects with every addition, change, or deletion of code. It is a well-documented fact that the number of bugs climbs linearly with the lines of code in a codebase, and it's understandably so—more the lines of code, more the opportunities a developer gets to make a mistake or create what I like to call implied knowledge. This is where a section of code appears to do something, but the real side effects of what it does, where it occurs in the code base, among other factors, are not obvious. They may be clear to the original developer, but to a new developer on a project, they are less so, and this generally leads to a lot of frustration.
Keeping the application logic structured and sensible without a strong knowledge of what you're doing is tougher in JavaScript and Node than most languages, and this can feel like a constant battle. Concepts such as control flow and error handling become painful if not managed early, and this is why I'm much more in favor of well-defined structures and consistent patterns when it comes to the layout of the code. hapi's request lifecycle and plugin API are good examples of this. Encapsulating your code inside a plugin gives it more context and structure, reducing the need for 'glue' code or implied knowledge.
I've found from the consistent structure which hapi's plugin API provides that hapi codebases are usually much easier to read, understand, and contribute to without any fear of breaking code or causing unknown side effects. I consider this a huge win for the framework—one of the most frustrating parts as a programmer is the phase of getting accustomed to a new code base. Reducing the time needed here makes for a much more productive and enjoyable experience as a developer. Let's look at the plugin API in more depth now.