Hapiとは|Walmart発の企業向けNode.jsフレームワーク

2026年6月3日

Hapiは2011年にWalmartLabsのEran Hammerが中心となって開発したNode.js向けのサーバフレームワークである。ブラックフライデーの巨大トラフィックを乗り切るために設計された経緯から、設定駆動の構成、プラグイン中心のモジュール化、入力バリデーションを厳格に組み込む方針が貫かれており、Expressとは異なる思想で発展してきた。本稿ではHapiの誕生背景、ルーティングと検証の仕組み、プラグイン設計、運用時の留意点まで筋道立てて解説する。

この記事の目次

Walmartでの誕生と方針転換
ルーティングとバリデーションの設計
プラグインアーキテクチャの活用
他Node.jsフレームワークとの対比
まとめ

Walmartでの誕生と方針転換

2011年のWalmartLabsはモバイルEC基盤の刷新を進めており、Node.jsで構築したサービスを感謝祭からブラックフライデーにかけてのピークで稼働させる必要があった。チームは当初Expressを使っていたが、ミドルウェアを積み重ねるアプローチではコードの所在が曖昧になり、設定とロジックが分離できないという課題に直面した。そこでEran Hammerが、宣言的な設定オブジェクトでサーバを組み立てる新フレームワークとしてHapiを起こした。

Hapiは名前のとおり「Hapi」イベントの参加者のように、各機能がプラグインとして登録される構造を採用する。コアは小さく保ち、認証、キャッシュ、ロギングなどはすべて公式・サードパーティのプラグインで補う。2014年にはWalmartLabsからコミュニティへガバナンスが移り、現在は独立した組織が継続している。

ルーティングとバリデーションの設計

Hapiのルートはserver.route({ method: 'GET', path: '/users/{id}', handler })のように設定オブジェクトで記述する。ハンドラは関数だけでなく、{ file: './public/index.html' }のような宣言値も受け取れるため、意図がコード上で明示される。リクエストが届くとHapiは認証、検証、前処理、ハンドラ、後処理という明確なライフサイクルを順に進める。

入力検証にはJoi（Hapiエコシステム発のスキーマライブラリ、現在は独立プロジェクト）を使用するのが慣例で、validate: { params: Joi.object({ id: Joi.string().uuid() }) }のように宣言する。検証は本体機能として実行されるためミドルウェアの順番を気にする必要がなく、ドキュメント生成プラグインhapi-swaggedと組み合わせるとOpenAPI仕様書を半自動で得られる。

プラグインアーキテクチャの活用

Hapiはserver.register(plugin, options)の形でプラグインを登録する。公式プラグインには静的ファイル配信のinert、テンプレートエンジン連携のvision、認証フレームワークのbell、セッション管理のyar、レート制限のhapi-rate-limitなどがあり、必要なものだけを宣言的に組み込める。

プラグインは名前空間とバージョンを持ち、依存をdependenciesで宣言できる。これにより大規模アプリでも機能境界が明確になり、テストや差し替えが容易である。実際にWalmartでは商品検索、カート、決済の各モジュールを独立したプラグインとして開発し、共通の設定駆動の枠組みの中で組み合わせていた。

他Node.jsフレームワークとの対比

Expressは2010年にTJ Holowaychukが作った最小限のルータで、自由度の高さが魅力だが構造はチームに委ねられる。Koaは2013年に同じ作者がasync/awaitを前提に設計した後継で、ミドルウェアの記述は簡潔になったが、やはり構成はライブラリ選定次第で大きく変わる。Fastifyは2016年に登場した高性能フレームワークで、JSONスキーマによる検証とコンパイル時最適化を武器に台頭してきた。

そのなかでHapiは「規約と検証を最初から備えた重め寄りのフレームワーク」という独自の立ち位置を持つ。速度では新しいFastifyに譲る場面があるが、エンタープライズで好まれる理由は、宣言的な設定、安定したAPI、公式プラグインの幅広さにある。長期保守を前提とする業務システムでは依然として有力な選択肢である。