従来のサーバーサイドレンダリング（SSR）、言い換えればハイパーメディア駆動アプリケーション（HDA）を用いてウェブアプリケーションを構築する場合、Reactのようなシングルページアプリケーション（SPA）フレームワークを用いた構築と比較して、発想の転換が必要です。
SPAエンジニアリングの考え方でこの開発スタイルに取り組むと、おそらく不満が生じ、このアーキテクチャ選択の多くの利点を逃してしまうでしょう。
スムーズに発想の転換を行い、このアプローチの長所を活かし、短所を最小限に抑えるための10個のヒントをご紹介します。
ハイパーメディア駆動アプローチの大きな利点は、ウェブアプリケーションの構築においてサーバーサイド環境をはるかに重要にすることです。単にJSONを生成するのではなく、バックエンドはウェブアプリケーションのユーザーエクスペリエンスにおいて不可欠なコンポーネントとなります。
そのため、そこで利用可能な機能を深く掘り下げる意味があります。多くの古いウェブフレームワークでは、HTML生成に関して非常に深い機能が利用できます。サーバーサイドキャッシュなどの機能は、非常に機敏なウェブアプリケーションと低速なユーザーエクスペリエンスの違いを生む可能性があります。
利用可能なツールをすべて学ぶ時間を取りましょう。
経験則として、アプリケーションのレスポンス完了にかかる時間を100ms未満にすることを目指し、成熟したサーバーサイドフレームワークにはこれを達成するためのツールが備わっています。
サーバーサイド環境には、多くの場合、コードを適切にファクタリング（または整理）するための非常に成熟したメカニズムがあります。モデル/ビュー/コントローラーパターンはほとんどの環境でよく開発されており、モジュール、パッケージなどのツールはコードを整理するための優れた方法を提供します。
SPAのユーザーインターフェースは通常コンポーネントによって整理されますが、ハイパーメディア駆動アプリケーションは通常テンプレートのインクルージョンによって整理されます。サーバーサイドのテンプレートはアプリケーションのHTMLレンダリングのニーズに従って分割され、必要に応じて互いにインクルードされます。これは、コンポーネントベースのアプリケーションで見られるよりも、より少なく、より大きなファイルにつながる傾向があります。
もう一つの検討すべき技術はテンプレートフラグメントです。これにより、テンプレートファイルの一部のみをレンダリングできます。これにより、サーバーサイドアプリケーションに必要なテンプレートファイルの数をさらに削減できます。
JSON APIとは異なり、ハイパーメディア駆動アプリケーションのために生成するハイパーメディアAPIは、特定のアプリケーションのUIニーズに特化したエンドポイントを備えているべきです。
ハイパーメディアAPIは汎用クライアントによる消費を目的として設計されていないため、汎用性を維持するというプレッシャーを脇に置き、アプリケーションに必要なコンテンツを具体的に生成できます。
エンドポイントは、汎用的なドメインモデルのためのデータアクセスモデルではなく、特定のアプリケーションのUI/UXニーズをサポートするように最適化する必要があります。
関連するヒントとして、ハイパーメディアベースのAPIを使用する場合、JSON APIベースのSPAを記述する場合に強く推奨されない方法でAPIを積極的にリファクタリングできます。ハイパーメディアをアプリケーション状態のエンジンとして使用するハイパーメディアベースのアプリケーションでは、アプリケーション開発者やユースケースが変化するにつれて、APIの形状を変更することができます。実際、推奨されます。
ハイパーメディアアプローチの大きな強みは、APIを完全に改良して時間の経過とともに新しいニーズに適応させることができ、APIのバージョン管理やドキュメント化を行う必要がないことです。
SPAアプローチを使用してアプリケーションを構築する場合、データストアは通常JSON APIの背後に存在します。この間接レベルにより、フロントエンド開発者はデータストアで利用可能なツールを最大限に活用できなくなることがよくあります。GraphQLはこれを解決するのに役立ちますが、多くの開発者には十分に理解されていないセキュリティ関連の問題を伴います。
一方、サーバーサイドでHTMLを生成する場合、そのHTMLを作成する開発者はデータストアにフルアクセスでき、たとえばSQLストアの結合や集約関数などを活用できます。
これにより、HTMLを生成する開発者の手に、はるかに表現力豊かな力が直接委ねられます。ハイパーメディアAPIをUIのニーズに合わせて構成できるため、各エンドポイントを調整して、データストアへのリクエストをできるだけ少なくすることができます。
経験則として、すべてのリクエストでデータストアへのアクセスを3回以下にすることを目指しましょう。
モーダルウィンドウは、今日の多くのウェブアプリケーションで一般的になり、ほぼ標準となっています。
残念ながら、モーダルウィンドウはウェブのインフラストラクチャの多くと連携が悪く、ハイパーメディアベースのアプローチとクリーンに統合するのが難しい（不可能ではないが）クライアントサイドの状態を導入します。
モーダルの代わりにインライン編集などの代替案を検討しましょう。
多くのSPA開発者がHDAアプローチに移行する際に直面する問題は、現在のSPAアプリケーションを見て、ハイパーメディアを使用してまったく同じように実装することを想像することです。htmxやその他のハイパーメディア指向のライブラリは、ハイパーメディアベースのアプリケーションとSPAの間のインタラクティブ性のギャップを大幅に縮めますが、そのギャップはまだ存在します。
ロイ・フィールディングがウェブのRESTfulネットワークアーキテクチャに関して述べたように
しかし、トレードオフは、統一されたインターフェースによって効率が低下することです。情報は、アプリケーションのニーズに特化した形式ではなく、標準化された形式で転送されるためです。
特定のUXに対するやや効率が悪く、インタラクティブ性が低いソリューションを受け入れることで、ウェブアプリケーションの構築における複雑さを大幅に削減できます。
完璧主義が良きものを妨げないようにしましょう。
ウェブアプリケーションのある時点で、ハイパーメディアアプローチだけでは不十分になる場合があります。
その良い例として、アイテムのリストの並べ替えがあります。これは、上下の矢印をクリックするか、アイテムの横に順番のドロップダウンを配置することで、「純粋な」ハイパーメディアで行うことができます。（どちらも作成したことを恥ずかしながら告白します！）
しかし、このエクスペリエンスは、人々が慣れているドラッグアンドドロップと比較して劣っています。
このような場合は、「インタラクティブ性の島」としてフロントエンド中心のアプローチを使用しても問題ありません。
SortableJSの例を考えてみましょう。ここでは、ドラッグアンドドロップを可能にする洗練されたインタラクティブ領域があり、イベントを介してhtmxおよびより広範なハイパーメディア駆動アプリケーションと統合されています。
これは、HDA内により豊かなUXをカプセル化するための優れた方法です。
スクリプト作成はウェブアーキテクチャの明示的な一部であり、ハイパーメディアアプローチを採用する開発者はそれを利用することを恐れるべきではありません。もちろん、スクリプト作成には様々な種類があります。
可能な限りハイパーメディアフレンドリーなスクリプト作成アプローチを使用し、システム状態の変更をサーバーと通信するための主要なメカニズムとしてハイパーメディア交換を維持する必要があります。
たとえばalpine.jsとhyperscriptによって有効にされたインラインスタイルのスクリプトも検討する価値があります。これは、スクリプトをハイパーメディア（HTML）自体に集中させ、記述できるコードの量に美的制約を課します。
最後に、ハイパーメディアの使用に教条的にならないようにしましょう。最終的には、独自の長所と短所を持つ別の技術に過ぎません。アプリケーションの特定の部分、またはアプリケーション全体が、ハイパーメディアが提供できるものよりもインタラクティブなものを必要とする場合、それを実現できるテクノロジーを使用しましょう。
ハイパーメディアで何ができるかを理解しておけば、情報に基づいた開発者としてその決定を下すことができます。
これらのヒントが、ハイパーメディアとサーバーサイドレンダリングをより効果的かつスムーズにツールとして採用するのに役立つことを願っています。完璧なクライアントサーバーアーキテクチャではなく、明示的なトレードオフが含まれていますが、多くのウェブアプリケーション（今日のほとんどのウェブ開発者が想像するよりもはるかに多い）にとって非常に効果的であり、そのようなケースでは、はるかにシンプルな全体的な開発エクスペリエンスを提供します。