htmxとハイパーメディアに対して時々耳にする異議の一つに、次のようなバリエーションがあります。
まあ、小さいものにはうまくいくかもしれないが、スケールしないだろう。
私たちをエッセイのネタで挑発するのは常に危険なので、この主張を少し掘り下げて、ハイパーメディア駆動アプリケーション（HDA）がスケール可能かどうかについて、少しでも光を当ててみましょう。
まず、「スケーリング」という用語を定義し、その言葉が開発で使われる文脈を定義しましょう。ソフトウェアの文脈では、スケーリングとは一般的に、ソフトウェアが「より大きな」ものを処理する能力を意味します。それらのものは、次のようになります。
これらの「スケーリング」という言葉のそれぞれの意味は、HDAに関して独自の分析を必要とします。
これは、自分のアプリケーションに関する意思決定を行う個々の開発者にとってはあまり関心のあることではありませんが、Webは分散ネットワーキングシステムとして非常にうまくスケールしていることを述べておく価値はあります。いずれにせよ、私が知っている中で最も成功した分散システムです。
これは個々のアプリケーション開発者にとっては必ずしも関心のあることではありませんが、適切なトーンを設定します。ハイパーメディアはスケール可能です。
ハイパーメディアはパフォーマンスにおいてうまくスケールするでしょうか？この質問に答えるために、まずパフォーマンススケーラブルなソフトウェアの特徴を見てみましょう。これらの特徴に関する信頼できる情報源はありませんが、ソフトウェアのスケーリング経験のあるほとんどのエンジニアは、このリストのほとんどの項目が少なくとも役立つことに同意するでしょう。
幸運なことに、適切に設計されたハイパーメディアシステムは、これらの特徴をすべて持つことができます。
ステートレスは、ロイ・フィールディングがWebを記述するために作成したRESTfulアーキテクチャの制約です。実際には、多くのハイパーメディア駆動アプリケーションは、サーバー側で少量の状態を管理するためにセッションクッキーを使用しますが、これはアプリケーションのスケーリングで致命的であることが証明されていないよく理解された手法です。
水平スケーリングは、ハイパーメディア駆動アプリケーションで長い歴史があり、ほとんどのハイパーメディア駆動アプリケーションのステートレスな性質と一致しています。たとえば、初期のPAASベンダーであるheroku（今は亡き）は、Rails駆動アプリケーションの簡単な水平スケーリングを提供していました。
機能の独立性は、HDAのもう1つの強みです。HDAでは、画面のエンドポイントは、一般的なJSON APIとは異なり、互いに分離される傾向があります。つまり、これらのエンドポイントは、相互に独立して監視、進化、調整できます。これらの種類のエンドポイントを調整して、100ミリ秒未満の応答時間を実現した長い歴史があります（例：SQLチューニングによる特定のエンドポイントのデータベースクエリの最小化）。
さまざまなビューをサポートするためのエンドポイントの独立性を基に構築することで、プラットフォームのパフォーマンスを簡単に監視および理解できます。アプリケーション全体で複数の方法でアクセスできる汎用化されたJSON APIではなく、特定のビューのハイパーメディアを構築するUI固有のエンドポイントがあります。ビューがサーバー側で構築され、リクエストが単純なハイパーメディア交換によって駆動される場合、パフォーマンスの問題の原因を特定することがはるかに簡単になります。
最後に、Webアプリケーションには、キャッシングの長く輝かしい歴史があります。HTTPは、ヘッダーによって制御されるブラウザでのキャッシュを提供します。Railsのような成熟したサーバーサイドフレームワークは、コントローラーレイヤーで洗練されたキャッシュを提供します。キャッシュはHDAにとっては第二の天性です。
これらすべてが組み合わさって、HDAはパフォーマンスの観点から非常にスケーラブルになります。ユーザー負荷の増加に合わせてHDAをスケーリングするために、実証済みのパフォーマンス技術を利用できます。
HDAのアプローチは、サーバー側により多くの計算をプッシュしますか？ある程度、これは事実です。ただし、特定のリソースのJSON表現とHTML表現の違いは、一部の人が考えているほど大きくはありません。特に、htmxベースのアプリケーションで一般的なように、HTMLリクエストにヘッダーとフッター情報を含めない場合はそうです。いずれにせよ、ネットワークの遅延とデータストアへのアクセスが通常リクエスト時間を支配し、SQL（または同様のサーバーサイドクエリ言語）を使用する機能により、リクエストのその側面を最適化する機会が得られます。
また、HDAは通常、自然に最適な「ビューごとの1つのリクエスト」を持っています。これは、HDAではリクエストがビューであるからです。
HDAは、一般的なJSONデータAPIではなく、UIのニーズによって駆動される独立したエンドポイントを持つ傾向があるため、機能の数によるスケーリングは通常非常に簡単です。サーバー側で合理的なモデル-ビュー-コントローラー分割を想定すると、コントローラーとモデルは互いに非常に独立している傾向があります。機能が本当に重複する場合、サーバー側で機能が開発およびテストされると、より制御されやすく、テスト可能な環境が提供されます。
ビューは、ほぼすべてのサーバーサイドテンプレートライブラリにあるサーバーサイドインクルードを介して再利用を実現したり、相互依存関係を回避するために個別に維持したりできます。
これはすべて、合理的なアプリケーションアーキテクチャを備えている場合、HDAはアプリケーションの機能の数で非常にうまくスケーリングされることが多いということです。特に、それらの機能が本質的に互いに切り離されている場合はそうです。
機能の数によるスケーリングは、あるレベルでは水平スケーリングに似ています。それらが比較的独立している限り、それらはうまくスケーリングします（そして、そうでない場合でも、HDAは他のオプションと同等かそれ以上にうまくスケーリングされることがよくあります）。
しかし、深い機能はどうでしょうか。それ自体が複雑な機能です。
ここで、深い機能を次の2つのカテゴリに分割する必要があります。
深いサーバーサイド機能の場合、HDAは優れた選択肢であることがよくあります。この良い例は、AIチャットボットのようなものです。これは非常に洗練されたサーバーサイド機能ですが、単純なテキストインターフェイスを介してユーザーと対話します。多くのAIチャットボットがhtmxを使用して構築されており、人々はそのシンプルさに感銘を受けています。
深いクライアントサイド機能の場合、HDAは優れた選択肢ではない場合があります。これに関する詳細は、ハイパーメディアを選択する時期に関するエッセイで概説しています。その記事を要約すると、UIが多数のイベントに迅速に応答する必要がある場合（例：マップビューのドラッグ）、またはバルクハイパーメディア交換で更新できない重要なUI間の依存関係がある場合（例：スプレッドシートアプリケーション）、ハイパーメディアアプローチはうまく機能しません。
ただし、次の2つの点に注意してください。
最後に検討するスケーリングの意味は、開発チームをスケーリングするという考えです。ここでは、残念ながら、より主観的で逸話的な尺度に頼る必要があります。
私たちの経験（および他の人々の経験）では、HDAを使用すると、より少ない開発者でより多くのことを達成できるように思われます。また、開発者が機能全体を担当するようになるため、フロントエンド/バックエンドの分割と、この分割のコミュニケーションの摩擦も解消されます。一部の人々はフロントエンド/バックエンドの分割を好み、これによりチームが独立することで、チームがよりうまくスケーリングできるようになると感じています。
私たちはそうは思いません。ほとんどのWebアプリケーションのフロントエンドとバックエンドは本質的に結合しており、したがって、最善のアプローチは、この結合を受け入れ、変更にうまく対処するように設計されたアーキテクチャを採用することであると考えています。これはハイパーメディアのアプローチが該当します（均一なインターフェイスを介して）。
HDAは100人以上のチームにスケールできますか？このシナリオを見たことがないため、これには答えられません。しかし、確かに10人単位にスケールできます。このアプローチがさらに高くスケールすると想像できますが（結局、Web 1.0時代にそうでした）、この時点では推測です。
いずれにせよ、私たちはより小さなチームを好みます。10人の開発者で、あらゆるアプリケーションに対応できるはずです。
したがって、これらをすべてまとめると、ハイパーメディア駆動アプリケーションのスケーリングに関して、次の結論が得られます。
HDAは、パフォーマンスと機能数に関して非常にうまくスケーリングできます。機能の複雑さに対しても、注意点がありますが、スケールできる可能性があります。そして最後に、チーム規模でのスケーリングについてはまだ結論が出ていませんが、HDAアプローチはチームを小さく保ち、チーム間のコミュニケーションの摩擦を解消する傾向があると言えます。