🎂 hapi pal v3: Birthday Edition

Today marks three years and one day from hapi pal's public release, and what a brilliant ride it has been! With an emphatic thank you to the community, we've prepared sweeping major releases across the ecosystem which mark a momentous milestone: we believe the core of hapi pal is feature complete, internally consistent, and stable.

We'd like to use this moment to take a breath, reflect on what we've accomplished over the past year, and see what's in store for the next.

If you're new to hapi pal

We maintain an ecosystem of tooling and best practices for the hapijs web framework, often with an eye towards challenging the "web" part of "web framework" to allow applications to go beyond HTTP to horizons such as CLI tools, programmatic usage, and serverless functions. The community is a rigorous yet friendly bunch, deeply interested and knowledgable about application architecture. That's our bag!

If you want to see what it looks like, you might follow our getting started guide, start a new project using the pal boilerplate, or dive into the weeds with in-depth examples such as the RealWorld API or a realtime, multiplayer wordgame. And by all means, come hang out in the #hapipal channel of the the official hapi hour Slack!

CHANGELOG_2020.md

No matter where in the world you live, 2020 was a year unlike any other. There's no denying that the global pandemic, cries for social justice, and sheer political uncertainty had a profound effect on what the past year looked like for hapi pal. It's almost too obvious to observe, but after all, hapi pal is comprised of people more so than code or anything else. Which brings us to Fishbowl...

Fishbowl

In April 2020 there were no birthday blog posts for pal— our second anniversary went by with a couple handfuls of "🎉"s and little more ceremony. But we were working on an important example application called Fishbowl, a realtime word game designed to be played in tandem with a video chat. It was built out of some kind of necessity, to stay connected to friends and family while separated by the pandemic, and put to good use by educators with their middle-school students in Maine, USA. This example utilizes the Docker support that had recently been contributed by @timcosta, three-tiered architecture, functional patterns, and in-process architecture prepared to be scaled out into individual services.

The hapi TSC

In July 2020 hapi's BDFL, Eran Hammer, announced that he would discontinue his involvement in the project. This caused an immense amount of chatter, ideation, and most of all uncertainty across the hapi ecosystem. It didn't take long for a group of hapi's core maintainers and original creators to come together with a plan, sparked largely by @cjihrig. The plan was to create a technical steering committee (TSC) to shepherd the project forward, but now based on open consensus and community contribution rather than a sole BDFL relying on commercial support, as outlined in our announcement.

It's no accident that two of the five current TSC members who came together are also core maintainers of hapi pal: myself @devinivy and @Nargonath. The most important investment hapi pal made this year was actually ensuring the stability of this framework that we rely on and care so much about. We're proud to have been a part of this effort, and if you ask us whether it was worth diverting some attention away from hapi pal itself, we'll give you an emphatic yes! It's made even sweeter by recurring support from our employers Big Room Studios and Dixeed to participate on the TSC.

The @hapipal/ scope

While plenty of effort went into Fishbowl and forming the hapi TSC, we additionally got in a fair amount of, let's say, traditional maintenance and improvements. At the beginning of September 2020 we began planning what could loosely be called "hapi pal v3" (and in fact is the third version of the pal boilerplate).

The goal from the outset has been to perform a "spring cleaning": tighten-up consistency in documentation, module APIs, repo conventions, and Node.js/hapi support. Along the way we cleaned-up old bugs, wrote some features, and dropped or downgraded support for anything that had proven less than useful over the years. The result is a stable, lean, consistent group of modules that we feel great about. One year ago the ecosystem was in good shape, but today we've really tightened the ratchet another full notch. To drive the point home that this is an important milestone, we also have chosen to do something that the community has wanted to do for at least a couple years: publish all modules under the @hapipal/ scope on npm.

Let's see a quick rundown of the changes!

• All modules have been published under the @hapipal/ scope with a major version bump. For example, the version after haute-couture v3 is @hapipal/haute-couture v4.
• All modules support node v12+ and hapi v19+. Any peer dependencies support the new, scoped module versions.
• The CI testing configuration has been unified across all modules.
• Schwifty's API has been simplified and adjusted to come into parity with schmervice's API. See the v6 migration guide.
• Haute-couture's API has been significantly simplified, and has adopted better defaults. See the v4 migration guide.
• Haute-couture now discovers TypeScript files, opening projects built using conventional pal tooling to properly interoperate with TypeScript.
• Toys has added support for async local storage, which will provide for some useful interoperability particularly with the hpal CLI. We're also taking advantage of new Node.js APIs, allowing us to remove a fair amount of code.
• Confidence has replaced yargs with hapi's standard CLI argument parser, bossy. This required working in the hapijs organization on bossy to keep confidence's original functionality in parity.
• The pal boilerplate has been updated to clean-up minor warts, incorporate exiting, and use all the latest module versions.
• The static site and custom swagger flavors of the boilerplate have been retired, although the fancy static site and plain swagger flavors will remain.
• The hpal CLI's hpal docs command has been updated to find documentation for the newly scoped module versions, as has hapipal.com/docs.
• hapipal.com has been updated to show module README docs in addition to API documentation.
• The website historically has run on Glitch with CloudFront in front of it for caching and improved uptime. Sometimes you'd hit a cold start on the Glitch project and have to wait some seconds to browse the website, so we're now on a plan with Glitch to keep the website up and running without delay or uptime limits.
• Hodgepodge and underdog have switched to ad hoc maintenance.
• All official examples in the examples repo, the RealWorld API, and Fishbowl have been updated with the latest module versions, boilerplate, and flavors.
• Along the way we made a slew of dependency upgrades to stay in sync with the hapijs ecosystem, and fixed a good handful of minor or newly-discovered bugs.
• Our writings have moved from our Medium, and will continue here on dev.to. This lends itself better to inviting guest writers, isn't adjacent to paywalls, and has support for important features such as syntax-highlighted code snippets and GitHub/Glitch/Twitter embeds.

This was a lot of work, but it was also manageable. When we say that hapi pal is "stable," it goes beyond the module APIs having solidified: we also mean that the 20+ repositories we manage are stable from a maintenance perspective. We don't see bugs piling up, dependencies going far out of date, etc., and that is because we have taken a measured approach to adopting new maintenance burdens; we do our best to keep dependencies within the pal and hapijs organizations where we have control and can avoid surprises; we strive to keep hapi pal open and extensible rather than tangled with tooling that folks choose to use alongside hapi pal. Today we have fewer than 25 open issues across 21 repositories, many of which are great first issues and features (feel free to hop in!)— and it doesn't require a bot arbitrarily closing issues to keep that count low.

So there it is, that was the past year in pal! 🎉

What's next?

The upcoming year in pal is going to be a great one. There are a few projects that the community has been itching to dive into, but we've held off while things settled for this big birthday release. With hapi governance back in balance, and all pal modules nicely in sync with each other, we can hop back into some of these projects. To be honest, we still have a fair amount of planning to do, but here's a preview of what I expect we'll start making headway on in the upcoming months.

🔗 TypeScript support

The TypeScript conversation in pal dates back to late 2019. Nothing has really barred users from using TypeScript in pal projects, and many modules already have definitions in DefinitelyTyped. At the same time, there were still some rough edges, particularly when using TypeScript with haute-couture, which we have addressed in this latest release. The next step is to start managing our own types, and we have a proposal about how to handle this given our constraints, plus a couple community members interesting in driving this work forward. While I don't expect to see modules rewritten in TypeScript, I do anticipate that next year we'll be talking about improved typings and continued quality of life improvements for those who choose to develop pal projects in TypeScript.

🍱 ES Modules

This year we'll start to hear more about ESM in Node.js, and the ripples across the entire Node.js ecosystem will start to become more apparent. The adoption of ESM is going to shake things up, so we're playing close attention to the situation as it develops. The most important action we can take in the short-term is maintain an open conversation, making our individual project needs known so that we can better understand the big picture of what ESM support will mean for the pal community. Per usual, we will also be coordinating with the hapijs organization to stay in step with the framework itself.

📚 More literature

Now that we're on dev.to, I believe it's going to be much simpler to invite community members to write about their experience with hapi pal. If all goes to plan, I hope to see more case studies, guides and tutorials, and general musings on application architecture. The conversations we have together in #hapipal are always illuminating for me— there's just so much experience and know-how spread across the community— and we've struggled to capture that in the past. I think one of the best ways to contribute to pal in 2021 will be to spread our knowledge and experience in this way.

The Best Practices section of the website could also use some attention. Over the past year I've personally heard a ton of interest on the topic of testing, and I think it would be a natural topic for us to expand upon.

👩‍🔬 Experimentation...

...in the application space

One of pal's ambitions has always been to enable the creation of flexible libraries in the application space (not just in tooling), based on hapi's powerful plugin architecture. Our core is at a great point to experiment more purposefully with writing reusable, customizable application services. Imagine a plugin which defined models and services for working with user accounts, that you could customize and incorporate deeply into your own application. Or a plugin that provided a headless blog API. Or an image-resizing service. Or the ability to easily make any entity in your application "commentable." We're just riffing at this point, but these are the kinds of experiments I'd love to see us performing this year.

...in the frontend space

There seems to be a trend: we think the server's becoming cool again, and that largely is driven by both advancements in the UI ecosystem (for example, React server components), and by an inclination back towards monolithic architecture for certain kinds of applications. In many ways hapi is well-suited to this, thanks to its ability to play both sides of monoliths and service-orientation through its concept of plugins, which can be deployed in either setting.

Historically hapijs hasn't been very involved in the frontend space, aside from its support for templated sites via vision (without which we would not have hapipal.com!). (Also, shoutout to @lynnaloo's Mullet from many years back!) In pal-land we've already started playing around with some novel server-side UI tooling in the space of server-side rendering, and will continue to iterate and share our results.

🤝 More collaborators

With the core of hapi pal solidified, we're in a better situation than ever to onboard new collaborators. I hope to become much more open about distributing responsibilities this year. If all goes well, we'll expand the number of community members with write access, and see more contributions this year than in any of the previous three years. To keep our applications safe and curb against abuse while inviting more people into the fold, we'll continue to keep publishing rights more limited and require 2FA.

If you're interested in participating, this list is a great place to get started. Or go bug-hunting, enhance some module documentation, run through the getting started tutorial and propose improvements. If none of that suits you, join us in #hapipal for a chat and we'll find something that suits your interests and abilities 🙏. All are welcome!

Thank you

It is such a pleasure to be part of this affable little slice of the Node.js ecosystem. We have a great thing going, and our intention is to keep it moving. Thanks for all the support, contributions, and great ideas from the past year. We're looking forward to another vibrant one between today and April 11th, 2022.

Here's to pal— big cheers! 🥂

Your pals,
Devin (@devinivy) and the pal team