3. その他 SPA にありがちな懸念点の検討 書き終わって読み直すに、いくつかの方法論は浮かぶが思った以上にやってみねぇと分からんという感じです。 ここでは SPA + SSR における完全な HTML を生成するサーバーサイドと、SPA + BFF (Backend For Frontend) くらいのゆるやかなサーバーサイドを別のアプローチとします。どのみち完全に静的な HTML と API サーバだけで複雑な SPA を成り立たせるのは無理があるので BFF の支援は前提に入ります。 また、SPA + SSR のダルさの根源は node の CPU ぶん回し対策や、キャッシュサーバーの管理などを伴うキャッシュストラテジーの煩雑性と定義します。単純に SPA + SSR を実現するだけなら道具も成熟してきているので、さほど難しくはなくなってきているという扱いにしておきます。 3-1.
App Shell モデルという設計パターン App Shell モデルは、共通のガワ部分を構成する HTML、CSS、JavaScript をシェルと定義し、その中に入る動的なコンテンツ部分と構造的に分離して扱えるように設計されます。 アプリケーション シェル(App Shell)アーキテクチャは、ネイティブ アプリのように瞬時に、そして確実にユーザーの画面に読み込める Progressive Web App を構築する方法の 1 つです。 アプリの「シェル」とは、ユーザー インターフェースが機能するために必要な最小限の HTML、CSS、JavaScript です。これらをオフラインで使用できるようにキャッシュしておくことで、ユーザーが同じページに再アクセスした際に、瞬時に高いパフォーマンス が発揮されます。つまり App Shell は、ユーザーがアクセスするたびにネットワークからす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く