従来の Web アプリケーションかシングル ページ アプリケーション (SPA) を選択する
ヒント
このコンテンツは eBook の「ASP.NET Core および Azure での最新の Web アプリケーションの設計」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。
"Atwood の法則: JavaScript で記述できるすべてのアプリケーションは、最終的に JavaScript で記述される"
- Jeff Atwood
現在、Web アプリケーションを構築するには、一般的に 2 つのアプローチがあります。サーバー上でアプリケーション ロジックの大部分を実行する従来の Web アプリケーションと、Web ブラウザーでユーザー インターフェイス ロジックのほとんどを実行し、主に Web API を使用して Web サーバーと通信するシングル ページ アプリケーション (SPA) です。 ハイブリッド アプローチも可能であり、最も単純なのは、高度な SPA のような 1 つ以上のサブアプリケーションを、より大規模な従来の Web アプリケーション内でホストする方法です。
次の場合は、従来の Web アプリケーションを使用します。
アプリケーションのクライアント側の要件が単純か、読み取り専用である。
JavaScript をサポートしていないブラウザーでアプリケーションが機能する必要がある。
アプリケーションは公開されており、検索エンジンでの検出や参照により利益を得ています。
次の場合は、SPA を使用します。
アプリケーションで、多くの機能を備えた高度なユーザー インターフェイスを公開する必要がある。
チームが JavaScript、TypeScript、または BlazorWebAssembly の開発に精通している。
他の (内部またはパブリック) クライアントに API を公開するという要件がアプリケーションに既にある。
さらに、SPA フレームワークには、より高度なアーキテクチャとセキュリティの専門知識が必要です。 従来の Web アプリケーションよりも頻繁な更新と新しいクライアント フレームワークにより、チームは大きな変化を経験します。 SPA アプリケーションでは、自動化されたビルドおよびデプロイ プロセスを構成し、コンテナーのようなデプロイ オプションを利用するため、従来の Web アプリケーションよりも困難になる可能性があります。
SPA の使用によって可能になるユーザー エクスペリエンスの向上と、これらの考慮事項を比較検討する必要があります。
Blazor
ASP.NET Core には、Blazor と呼ばれる、機能が豊富で構成可能な対話型ユーザー インターフェイスを構築するためのモデルが含まれています。 サーバー側 Blazor を使用すると、開発者はサーバー上で C# と Razor を使用して UI を構築し、永続的な SignalR 接続を使用して、リアルタイムで UI をブラウザーと対話的に接続させることができます。 BlazorWebAssembly では、Blazor アプリに対して別のオプションが導入されます。WebAssembly を使用して、それらをブラウザーで実行できます。 WebAssembly で実行される実際の .NET コードであるため、アプリケーションのサーバー側の部分からコードとライブラリを再利用できます。
Blazor には、完全にサーバー側でレンダリングされる Web アプリケーションまたは SPA をビルドするかどうかを評価する場合に検討する、新しい 3 つ目のオプションが用意されています。 多くの JavaScript 開発を行うことなく、Blazor を使用して、SPA に似た豊富なクライアント側の動作を構築できます。 Blazor アプリケーションでは、API を呼び出してデータを要求したり、サーバー側の操作を実行したりできます。 JavaScript ライブラリとフレームワークを利用するために必要な場合は、JavaScript と相互運用できます。
次の場合は、Blazor を使用して Web アプリケーションをビルドすることを検討してください。
アプリケーションで高度なユーザー インターフェイスを公開する必要がある
チームは JavaScript や TypeScript の開発よりも .NET の開発に慣れている
.NET Core または最新の .NET への移行を検討している既存の Web Forms アプリケーションがある場合は、Web Forms 開発者向け Blazor の無料の電子書籍を確認し、Blazor への移行を検討するのが理にかなっているかどうかを確認することができます。
Blazor の詳細については、Blazor の概要に関するページを参照してください。
従来の Web アプリケーションを選択する場合
以下のセクションでは、前述した従来の Web アプリケーションを選択する理由について詳しく説明します。
アプリケーションは単純で、場合によっては読み取り専用であり、クライアント側の必要条件がある
多くの Web アプリケーションは、大多数のユーザーが主に読み取り専用で使用しています。 読み取り専用 (または読み取り主体) のアプリケーションは、大量の状態を維持および操作するアプリケーションよりもはるかに単純である傾向があります。 たとえば、検索エンジンは、テキストボックスを使用した 1 つのエントリ ポイントと、検索結果を表示するための 2 番目のページで構成されます。 匿名ユーザーは簡単に要求を実行することができます。クライアント側のロジックはほとんど必要ありません。 同様に、ブログやコンテンツ管理システムの公開アプリケーションは、通常、主にクライアント側の動作がほとんどないコンテンツから構成されています。 このようなアプリケーションは従来のサーバーベースの Web アプリケーションとして簡単にビルドでき、Web サーバー上でロジックを実行し、ブラウザーに表示する HTML をレンダリングできます。 サイトの個々のページには、ブックマークを追加し、検索エンジンでインデックスを付けることができる独自の URL があります (既定では、アプリケーションの個別の機能としてこの機能を追加する必要はありません)。このようなシナリオでは、この点は明らかな利点でもあります。
JavaScript をサポートしていないブラウザーでアプリケーションが機能する必要がある
JavaScript のサポートが限られている、またはサポートされていないブラウザーで機能する必要がある Web アプリケーションは、従来の Web アプリケーションのワークフローを使用して作成する必要があります (または、少なくともそのような動作にフォールバックできる必要があります)。 SPA が機能するには、クライアント側の JavaScript が必要です。JavaScript を利用できない場合は、SPA は推奨されません。
チームが JavaScript や TypeScript の開発手法に精通していない
チームが JavaScript や TypeScript に精通しておらず、サーバー側の Web アプリケーション開発に精通している場合は、SPA よりも従来の Web アプリケーションの方が短時間で提供できる可能性があります。 SPA のプログラミングを習得することが目標の場合や、SPA が提供するユーザー エクスペリエンスが必要な場合を除き、従来の Web アプリケーションは、その構築に既に精通しているチームにとってはより生産的な選択肢です。
SPA を選択する場合
以下のセクションでは、Web アプリケーションにシングル ページ アプリケーション スタイルの開発を選択する場合について詳しく説明します。
アプリケーションで、多くの機能を備えた高度なユーザー インターフェイスを公開する必要がある
SPA は、ユーザーが操作を行ったり、アプリケーションの各領域間を移動したりするときに、ページの再読み込みが必要ない、高度なクライアント側の機能をサポートできます。 SPA は読み込み時間が高速で、バックグラウンドでデータを取得します。ページ全体が再読み込みされることはまれなので、各ユーザー アクションの応答性が向上します。 SPA は増分更新をサポートできるので、ユーザーがボタンをクリックしてフォームを送信しなくても、部分的に完了したフォームまたはドキュメントを保存することができます。 SPA は、従来のアプリケーションよりもはるかに簡単に、ドラッグアンドドロップなどの高度なクライアント側の動作をサポートできます。 SPA は、切断されたモードで動作するように設計し、接続が再確立したときに、最終的にサーバーに同期されるようにクライアント側モデルを更新できます。 一般的な HTML フォームによって提供される機能を超える豊富な機能がアプリケーションの要件に含まれている場合は、SPA スタイルのアプリケーションを選択します。
従来の Web アプリケーションに組み込まれている機能の実装が SPA で必要になることはよくあります。たとえば、アドレス バーに現在の操作を反映したわかりやすい URL を表示する機能 (そしてユーザーがブックマークやディープ リンクを作成してこの URL に戻ることができる機能) などです。 また、SPA では、ユーザーがブラウザーの [戻る] ボタンと [次に進む] ボタンを使用したときに驚くような結果にはなりません。
チームが JavaScript や TypeScript の開発に精通している
SPA を作成するには、JavaScript や TypeScript と、クライアント側のプログラミング手法とライブラリに精通している必要があります。 チームには、Angular のような SPA フレームワークを使用して最新の JavaScript を記述できる能力が必要です。
参考資料 - SPA フレームワーク
- Angular: https://angular.io
- React: https://reactjs.org/
- Vue.js: https://vuejs.org/
他の (内部またはパブリック) クライアントに API を公開するという要件がアプリケーションに既にある
他のクライアントが使用する Web API をサポートしている場合は、サーバー側のフォームでロジックを再現するのではなく、このような API を利用する SPA 実装を作成する方が簡単な可能性があります。 ユーザーがアプリケーションを操作すると、SPA は多数の Web API を使用してデータのクエリと更新を行います。
Blazor を選択する場合
以下のセクションでは、Web アプリケーションのために Blazor を選択する理由について詳しく説明します。
アプリケーションで高度なユーザー インターフェイスを公開する必要がある
JavaScript ベースの SPA と同様に、Blazor アプリケーションでは、ページの再読み込みなしで高度なクライアントの動作をサポートできます。 これらのアプリケーションでは、特定のユーザーの操作に応答するために必要なデータ (または HTML) のみがフェッチされるため、ユーザーへの応答性が高くなります。 この機能がサポートされた後、最小限の変更によって、適切に設計されたサーバー側の Blazor アプリをクライアント側の Blazor アプリとして実行されるように構成できます。
チームは、JavaScript や TypeScript の開発よりも .NET の開発に慣れている
多くの開発者は、JavaScript や TypeScript などのクライアント側の言語よりも .NET と Razor のほうが生産性が優れています。 アプリケーションのサーバー側は既に .NET で開発されているため、Blazor を使用することで、チームのすべての .NET 開発者がアプリケーションのフロント エンドの動作を理解して構築できます。
意思決定テーブル
次の意思決定テーブルは、従来の Web アプリケーション、SPA、または Blazor アプリのどれかを選択する場合に考慮する基本的な要素の一部をまとめたものです。
| 要素 | 従来の Web アプリケーション | シングル ページ アプリケーション | Blazor アプリ |
|---|---|---|---|
| チームに必要な JavaScript/TypeScript の精通度 | 最小限 | 必須 | 最小限 |
| スクリプトを作成せずにブラウザーをサポート | サポート状況 | サポートされない | サポート状況 |
| 最小限のクライアント側アプリケーションの動作 | 適している | 過剰 | 実行可能 |
| 高度で複雑なユーザー インターフェイス要件 | 制限がある | 適している | 適している |
その他の注意事項
従来の Web Apps は、SPA アプリよりも、単純で検索エンジンの最適化 (SEO) の基準が優れている傾向があります。 検索エンジンのボットは、従来のアプリのコンテンツを簡単に使用できる一方で、SPA のインデックス作成のサポートがないか限定的である可能性があります。 アプリに検索エンジンによる公開検出のメリットがある場合、これがしばしば重要な考慮事項になります。
さらに、SPA のコンテンツ用に管理ツールを構築している場合を除き、開発者が変更を加える必要がある場合があります。 従来の Web Apps は、しばしば簡単で、開発者以外が変更を加えることができます。コンテンツの多くは単なる HTML であり、プレビューやデプロイにビルド プロセスが必要ない場合もあります。 組織で開発者以外がアプリのコンテンツをメンテナンスする可能性がある場合は、従来の Web アプリの方が適している可能性があります。
アプリに複雑な対話型のフォームまたはその他のユーザーとの対話機能がある場合、SPA は輝きます。 認証を使用する必要がある、公開検索エンジン スパイダーからアクセスできない複雑なアプリの場合、SPA は多くの事例で最適なオプションです。
.NET