従来の Web アプリとシングル ページ アプリ (SPA) から選択する

「Atwood の法則: JavaScript で記述できるアプリケーションは、最終的に JavaScript で記述されます。
- Jeff Atwood

現在、Web アプリケーションを構築するための一般的な方法は 2 つあります。サーバー上でほとんどのアプリケーション ロジックを実行する従来の Web アプリケーションと、Web ブラウザーでほとんどのユーザー インターフェイス ロジックを実行するシングルページ アプリケーション (SPA) は、主に Web API を使用して Web サーバーと通信します。 ハイブリッド アプローチも可能です。最も単純なのは、大規模な従来の Web アプリケーション内で 1 つ以上の豊富な SPA のようなサブアプリケーションをホストすることです。

従来の Web アプリケーションは、次の場合に使用します。

• アプリケーションのクライアント側の要件は単純であるか、読み取り専用です。

• アプリケーションは、JavaScript をサポートしていないブラウザーで機能する必要があります。

• アプリケーションは一般向けであり、検索エンジンの検出と紹介の利点があります。

SPA は次の場合に使用します。

• アプリケーションでは、多くの機能を備えたリッチ ユーザー インターフェイスを公開する必要があります。

• チームは、JavaScript、TypeScript、または BlazorWebAssembly 開発に精通しています。

• アプリケーションは、他の (内部またはパブリック) クライアント用の API を既に公開している必要があります。

さらに、SPA フレームワークには、より高いアーキテクチャとセキュリティの専門知識が必要です。 従来の Web アプリケーションよりも頻繁な更新と新しいクライアント フレームワークにより、変更頻度が高くなります。 自動化されたビルドおよびデプロイ プロセスを構成し、コンテナーなどの展開オプションを利用することは、従来の Web アプリよりも SPA アプリケーションでは困難な場合があります。

SPA アプローチによって可能になったユーザー エクスペリエンスの向上は、これらの考慮事項に照らして考慮する必要があります。

Blazor

ASP.NET Core には、 Blazorと呼ばれる豊富でインタラクティブで構成可能なユーザー インターフェイスを構築するためのモデルが含まれています。 Blazor サーバー側を使用すると、開発者はサーバー上に C# と Razor を使用して UI を構築し、永続的な SignalR 接続を使用して UI をリアルタイムでブラウザーに対話形式で接続できます。 Blazor WebAssembly では、 Blazor アプリ用の別のオプションが導入されており、 WebAssemblyを使用してブラウザーで実行できます。 WebAssemblyで実行されている実際の .NET コードであるため、アプリケーションのサーバー側の部分からコードとライブラリを再利用できます。

Blazor は、純粋にサーバーでレンダリングされた Web アプリケーションと SPA のどちらを構築するかを評価する際に考慮する新しい 3 番目のオプションを提供します。 javaScript の大幅な開発を必要とせずに、 Blazorを使用して、豊富な SPA に似たクライアント側の動作を構築できます。 Blazor アプリケーションは API を呼び出してデータを要求したり、サーバー側の操作を実行したりできます。 必要に応じて、JavaScript ライブラリとフレームワークを利用するために、JavaScript と相互運用できます。

次の場合は、 Blazor を使用して Web アプリケーションを構築することを検討してください。

• アプリケーションでリッチ ユーザー インターフェイスを公開する必要がある

• チームは、JavaScript や TypeScript 開発よりも .NET 開発に慣れている

.NET Core または最新の .NET への移行を検討している既存の Web フォーム アプリケーションがある場合は、Blazor無料の電子書籍を確認して、Blazorへの移行を検討するのが理にかなっているかどうかを確認できます。

Blazorの詳細については、「Blazorを始めましょう」を参照してください。

従来の Web アプリを選択するタイミング

次のセクションでは、従来の Web アプリケーションを選択する前に説明した理由について詳しく説明します。

アプリケーションには、クライアント側の要件が単純で、読み取り専用である可能性があります

多くの Web アプリケーションは、主にユーザーの大半によって読み取り専用の方法で使用されます。 読み取り専用 (または読み取りがほとんど) のアプリケーションは、非常に多くの状態を維持および操作するアプリケーションよりもはるかに単純になる傾向があります。 たとえば、検索エンジンは、テキスト ボックスと検索結果を表示するための 2 番目のページを含む 1 つのエントリ ポイントで構成される場合があります。 匿名ユーザーは簡単に要求を行うことができます。クライアント側のロジックの必要はほとんどありません。 同様に、ブログやコンテンツ管理システムの一般向けアプリケーションは、通常、クライアント側の動作がほとんどないコンテンツで構成されます。 このようなアプリケーションは、Web サーバー上でロジックを実行し、HTML をブラウザーに表示する従来のサーバー ベースの Web アプリケーションとして簡単に構築できます。 サイトの一意の各ページには、検索エンジンによってブックマークとインデックスを作成できる独自の URL (既定では、アプリケーションの別の機能としてこの機能を追加する必要はありません) があることも、このようなシナリオでは明確な利点です。

JavaScript をサポートしていないブラウザーでアプリケーションを機能させる必要がある

JavaScript のサポートが制限されているか、またはサポートされていないブラウザーで機能する必要がある Web アプリケーションは、従来の Web アプリ ワークフローを使用して記述する必要があります (または、少なくともそのような動作にフォールバックできます)。 SPA を機能させるには、クライアント側の JavaScript が必要です。使用できない場合は、SPA は適切な選択肢ではありません。

チームが JavaScript または TypeScript の開発手法に慣れていない

チームが JavaScript または TypeScript に慣れていないが、サーバー側の Web アプリケーション開発に慣れている場合は、SPA よりも迅速に従来の Web アプリを提供できる可能性があります。 SPA のプログラミングを学習することが目標であるか、SPA によって提供されるユーザー エクスペリエンスが必要でない限り、従来の Web アプリは、既に構築に慣れているチームにとって、より生産的な選択肢です。

SPA を選択するタイミング

次のセクションでは、Web アプリの開発のシングル ページ アプリケーション スタイルを選択するタイミングについて詳しく説明します。

アプリケーションでは、多くの機能を備えたリッチ ユーザー インターフェイスを公開する必要があります

SPA は、ユーザーがアクションを実行したり、アプリの領域間を移動したりするときにページを再読み込みする必要のない、クライアント側の豊富な機能をサポートできます。 SPA は、より迅速に読み込み、バックグラウンドでデータをフェッチでき、ページ全体の再読み込みはほとんどないため、個々のユーザー アクションの応答性が向上します。 SPA は増分更新をサポートでき、ユーザーがボタンをクリックしてフォームを送信しなくても、部分的に完了したフォームまたはドキュメントを保存できます。 SPA では、従来のアプリケーションよりもはるかに簡単に、ドラッグ アンド ドロップなどの豊富なクライアント側の動作をサポートできます。 SPA は、接続が再確立されると最終的にサーバーに同期されるクライアント側モデルに更新を行い、切断モードで実行するように設計できます。 アプリの要件に、一般的な HTML フォームが提供する機能を超える豊富な機能が含まれている場合は、SPA スタイルのアプリケーションを選択します。

多くの場合、SPA では、現在の操作を反映した意味のある URL をアドレス バーに表示するなど、従来の Web アプリに組み込まれている機能を実装する必要があります (ユーザーがこの 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 アプリは、SPA アプリよりも単純で、検索エンジンの最適化 (SEO) 基準が優れている傾向があります。 検索エンジン ボットは従来のアプリのコンテンツを簡単に使用できますが、SPA のインデックス作成のサポートが不足しているか制限されている可能性があります。 アプリが検索エンジンによるパブリック検出の恩恵を受けた場合、これは多くの場合、重要な考慮事項です。

さらに、SPA のコンテンツの管理ツールを構築していない限り、開発者が変更を加える必要がある場合があります。 従来の Web アプリは、多くの場合、開発者以外が変更を加えるのが簡単です。コンテンツの多くは単なる HTML であり、プレビューやデプロイにビルド プロセスを必要としない場合があるためです。 組織内の開発者以外がアプリのコンテンツを維持する必要がある可能性が高い場合は、従来の Web アプリが適している可能性があります。

SPA は、アプリに複雑な対話型フォームまたはその他のユーザー操作機能がある場合に機能します。 認証を使用する必要があり、パブリック検索エンジンのスパイダーからアクセスできない複雑なアプリの場合、SPA は多くの場合に最適なオプションです。