Why you should consider hapi

When starting a new web application, your first decision is the platform: node, Go, Rails, etc. Your second decision is the framework. When it comes to node, there are plenty of great frameworks to choose from .

Here is why hapi should be at the top of your list.

From the early days of node, hapi was the first enterprise-grade solution. Originally developed to support Walmart Black Friday scale, hapi retained that reputation thanks to its proven track record. You probably use at least one hapi-powered web application every day without even knowing it.

Quality

On practically every measurable quality metric, hapi scores at the very top.

Code Readability

I’ll start with what I consider to be the most important measure of quality ― code readability . If you pick a node framework and cannot follow the code with ease, that’s a red flag. Code readability correlates directly to what should matter most: simplicity, security, and maintainability .

It makes all the difference in the world when something goes wrong and you need to figure out what. Almost every major issue found over the past few years was reported with a solution because the code is that easy to work with. When readability and performance are in conflict, I will always choose readability. Machines keep getting faster and cheaper. Humans only get slower and more expensive.

Because the code is not micro-optimized to squeeze every bit of unnecessary performance , changes do not require complex, messy solutions. hapi will never be the fastest framework because avoiding complexity is a mantra I repeat to myself with every line of code I write or review.

Dependencies

hapi was the first (and still the only) framework without any external code dependencies. (It has one external dependency on a static JSON data file for mime types). Every code dependency is managed and controlled by our small core team and the final integrated solution is controlled solely by me.

I personally (and manually) review every single line of code that goes into hapi (excluding node itself). I review every pull request on every dependency regardless if I am the lead maintainer.

When you ‘npm install hapi’, every line of code you get has been verified. You never have to worry about some deep dependency being poorly maintained (or handed over to an unknown or sketchy individual).

If you followed recent new s, this is a big deal.

Code Coverage and Style

hapi was the first node project to require 100% code coverage . When existing code coverage tools where not good enough, we wrote our own. We were among the first to define a strict coding style enforced in CI. We keep revisiting our style as new, better approaches are developed and then move the entire code base to the new standard proactively.

Open Issues

The entire framework consists of 27 modules. Excluding joi which is its own (validation) framework (and mime-db which is a static data file), the rest of the modules combined have 6 open pull requests, 9 open reported issues, and 19 open feature requests or questions.

These are mind blowing low numbers, especially considering hapi is the second most used node framework with an average of over 1.3 million monthly downloads. Few other projects maintain such low numbers of open issues. This isn’t easy ― it takes significant effort to achieve.

Security

I might not be thrilled with the final result of the OAuth specification I co-authored, but I have made sure to build hapi with the strictest security-first approach. To this day, it is the only framework that can claim that. In hapi, security is never an afterthought or an add-on. It is central to the way we do everything.

Code Hygiene

From how the code is managed, controlled, and distributed, we always choose the most secure option available. Every contributor must have 2FA enabled on both GitHub and npm. Every publish must use 2FA. The core framework comes with a shrinkwrap file that specifies the integrity hash of every dependency. And soon we will automate the process of ensuring the code in GitHub matches the packages on npm.

Secure Defaults

Every default is always the most secure option available. hapi blocks error messages that may leak information or echo back exploits at multiple levels. Server load is protected by default with payload limits and request timeouts. And as more standards become available, new security headers are added to the core framework.

Integrated Architecture

On the application side, hapi provides the most comprehensive authorization and authentication API available in a node framework. Request authentication is a core part of the request lifecycle, not some middleware you throw in (hopefully correctly and in the right place and order).

And for the super security conscious of us, hapi provides advanced features such as encrypted and signed cookies and secret or key rotation. There are no possible excuses for building insecure applications.

Developers First

Every hapi feature is built with the application developer in mind. When adding new features, I always ask myself if this makes things more or less intuitive. At the end of the day, the question I care most about when talking to hapi users is “are you happy?”

Not everyone is going to agree with every choice I make, and there are many different valid approaches to building web applications. But rarely has someone invested in hapi to later regret that decision. I keep asking.

In survey after survey, hapi developers are among the very top on satisfaction. This is one metric I have no problems bragging about.

Predictability

One of the main reasons I built hapi instead of using Express was the total lack of predictability. The order in which you added routes, middleware, or called server-level methods dictated the outcome, often with hidden side effects. As projects got bigger, things broke on a daily basis when one middleware stepped over another or when a route path pattern overlapped with an existing route.

hapi was the first node framework (and still one of the very few, if not the only) to provide strong guarantees, empowering large distributed teams to work together on a common code base.

If you load a plugin that requires other plugins, it can explicitly specify it. If you are adding extension points, you can specify their relative order so that future extensions will not disrupt the existing balance. Route paths will never conflict and will always result in the same priority order no matter what order they are added.

Extensibility and Customization

hapi practically invented node framework plugins, the request lifecycle, server methods, and user extensions. It has the most mature and complete set of extension points at every step including authentication, authorization, and validation. You never have to hack your way around the framework and the internals are never a mystery. Every step is clearly documented.

In hapi, everything is properly namespaced which makes extensions safe and easy to use. You never have to worry about your application failing in production because of a runtime conflict between two extensions or plugins. Everything is validated in load-time for easy identification of conflicts during development.

The Rest

These are just the highlights. I didn’t even talk about the configuration-centric approach. The built in validation in and out. The caching support. The rich plugins ecosystem. Using the very latest JS language features…

But I do want to give a shout out to the hapi community. I have never been part of a better, more supportive and protective group of people. From answering questions on GitHub to offering help on Slack, the hapi community has some of the nicest, smartest folks around.

So for your next node project, give hapi a look. I think you are going to like it.