Today we are overjoyed to announce hapi pal, a suite of tools and best practices for the working hapijs developer. We have invested years of energy into what we have found to be a delightful, sustainable approach to developing web services using nodejs, and it’s finally time to open up.
What is hapi?
If you’re not familiar with hapijs, it’s an open-source web framework for nodejs that got off the ground with a 2+ million dollar investment from Walmart Labs and now operates entirely through an open governance model. (Sometimes we joke that we’re driving the Rolls Royce of web frameworks.) The framework is extensive, offering a uniquely rich plugin architecture and ecosystem, integrated concepts of caching, authentication and authorization, a strong community, and an emphasis on stability and security. It touts itself as “enabling developers to focus on writing reusable application logic instead of spending time building infrastructure.” And it really does — it’s a beautiful thing. We’re familiar with the alternative frameworks, those both well-established and new, and we find ourselves regularly renewing our vows with hapi.
But it’s important to note that the core hapi organization has intentionally remained unopinionated about how to author applications using hapi. The framework only offers a programming interface: there’s no directory structure, concrete deployment strategy, model or service/business layer, and generally no suggested architecture whatsoever. To be honest, we think that this is totally fair on hapi’s part. For one, there are only so many resources to spend on hapi development, so not focusing on additional tooling means that the rest of the framework is more stable and fully-featured. And secondly, we’re glad they’ve made room for the community to experiment.
For this reason, we found it invaluable to create for ourselves common conventions, tooling, and patterns that jive with hapi. Big Room Studios takes on a lot of projects, and there are incentives — for our business and those of our customers — to avoid solving the same problem or making the same decision too many times, which our development team understands acutely. It’s important for us to share a common knowledge base, to be able to onboard new developers easily, to have consistency across projects that enables us to effectively perform long-term maintenance. These issues are probably familiar to you too. Our solutions to these issues, refined over the course of nearly four years, constitute hapi pal.
Building a set of tools
You can think of hapi pal as a methodology for building hapi apps, backed both by software and written articles to guide you. While consulting on others’ hapi deployments, we find certain hapi features to be underutilized, often simply because they are covered without much ceremony in the hapi docs, or for other superficial reasons: sometimes it can be hard enough to decide where to put some code that you fall back to familiar techniques. We think that this is a very real, valid conceptual gap, and that it’s worth closing for the betterment of the community. We want to make it simpler to learn the framework, and to bring the most powerful features of hapi into reach. No single aspect of pal is required (we’ve incrementally adopted these tools ourselves) but here are some things pal has to offer:
- hpal — A CLI tool for searching hapi-related documentation, starting new projects, scaffolding existing projects, and running custom commands in the context of your project.
- the pal boilerplate — A generic boilerplate setup for testing, linting, development, and deployment while enforcing 12factor practices and pluginization of your app. The boilerplate can be customized using “flavors,” which add common functionality, e.g. database integration, templated views, Swagger API documentation, and more.
- haute-couture — A plugin composer that wires-up your plugin for you based upon a (customizable) directory structure. Rather than calling
server.route(), place route configurations in the
routes/folder; implement your auth strategies in
auth/strategies/; register additional plugins by configuring them in
plugins/; define models in
models/; services in
- schwifty — A model layer for dialects of SQL based on the inimitable Objection ORM.
- schmervice — A service layer that integrates with hapi caching.
- hecks — Interoperability with express applications.
- underdog — A plugin adding support for HTTP/2 server-push.
- tandy — A plugin that helps auto-generate CRUD routes for your models.
- toys — A collection of hapi-oriented helpers.
- best practices — A growing list of articles on idiomatic hapijs app development.
- More, including a package that helps resolve hairy inter-plugin dependencies (hodgepodge).
A hapi pal when you need it
Now, I’m specifically not here to claim that hapijs or hapi pal are going to allow to you to ship complex features with tight SLAs to millions of users in a matter of minutes, hours, or days: one of our founding design principles is acknowledging that building scalable web services is hard work. We know this because we’ve built tons of them, and in plenty of different languages and frameworks: there’s no silver bullet. So we’re not interested in any platform that gets in our way when it comes time for heavy lifting. When that time comes, wouldn’t you rather just have a pal to cheer you on, offer you a hand and moral support, and leave you to your own devices if you don’t really need the extra help? That’s what hapi pal is all about.
Sponsored and maintained
And did we mention hapi pal is sponsored?! Big Room Studios has demonstrated a commitment to open-source software through development and design of hapipal.com, development of schwifty and tandy, lots of dogfooding, and the ongoing maintenance of numerous pal and hapijs modules. The hapi pal organization is openly governed, but Big Room has helped make this initial release a reality, and plans to support several of us in our maintainership of hapi pal going forward. We’re thankful for that because we love using and writing well-maintained software. Now, don’t get us wrong — there’s still a lot of work to do and we could use your help too.
So, come check it out. Join us — we’d love to have you! If you’re already a part of the hapi community, we hope you’ll be pleased to learn that hapi pal is designed to be entirely compatible with the hapi organization. We have the same code style, identical issue labels, the same standard of 100% code coverage, and a consistent code of conduct, all of which we are quite familiar with, as some of us are also core and community hapi collaborators. We will continue to move in step with the hapi organization, and we earnestly look forward to seeing where we end up. Also, be on the lookout for some big new pal capabilities on the horizon. We have some fun plans — come chat with us about them in our #hapipal channel in the hapi hour Slack. Hope to see you there.