そのため、私の会社はアプリケーション用のマイクロ フロントエンド アーキテクチャに取り組んでいます。これは私がここで開拓してきたプロジェクトであり、これまでのところ非常に成功しています。ただし、私たちの未解決の課題の 1 つについてアドバイスをいただければ幸いです。
Webpack を使用して JavaScript アプリケーションを作成する場合、オプションの 1 つは URL にハッシュを追加することです。このハッシュはビルドごとに生成されるため、ハッシュはファイル自体に変更がある場合にのみ変更されます。したがって、ファイル名は次のようになります。
app.ab12cd.js
これを行う利点は、ブラウザのキャッシュです。ブラウザは、大量のデータを消費するのを避けるために、物事をキャッシュしようとします。そのため、同じファイル名/URL が再度検出された場合、再ダウンロードするのではなく、キャッシュされたバージョンを使用するだけです。ファイル名のハッシュは、ファイルが変更されて再構築された場合にのみ変更されるため、ブラウザーがこのファイルをキャッシュすることを安全に信頼して、ユーザーの有線ダウンロードの負担を軽減しながら、ユーザーが常に変更を加えることを確信できます。最新の変更を参照してください。
これは、当社のマイクロ フロントエンド アーキテクチャの課題です。指針となる原則の 1 つは、各マイクロ フロントエンドを個別にリリース可能にすることです。つまり、ベース アプリケーション (つまり、ユーザーが移動する最初のアプリケーション) とそれがロードするマイクロ フロントエンド アプリとの間に直接的な依存関係はありません。
これは、単純な静的タグを使用して実現します。新しいマイクロ フロントエンドを追加するたびに、新しいタグを追加するためにベース アプリケーションを 1 回更新するだけで済みます。
<script src="micro-frontend/assets/js/app.js"></script>
上記の例では、その URL は nginx プロキシを使用して、実際にデプロイされたマイクロ フロントエンドにリダイレクトされます。これは、私たちの企業インフラストラクチャに関連する愚かで苛立たしい理由による相対 URL ですが、それはまったく別の話です。
要点は、「app.12ab34.js」ではなく「app.js」を指していることに気付くでしょう。マイクロフロントエンドが変更されるたびにベースアプリケーションを更新したくないため、ハッシュを使用していません。代わりに、キャッシュ コントロール ヘッダーを返して、マイクロ フロントエンドのブラウザー キャッシュを防止します。
これも理想的ではありません。独立性を得る一方で、マイクロ フロントエンド コードのキャッシュが失われるからです。
それで、私の質問: マイクロ フロントエンドのファイル名でハッシュを有効にする場合、ハッシュの変更のために更新する必要がないようにベース アプリケーションをセットアップする方法はありますか? 言い換えれば、私がまだ考えていない、これらのアプリを接続するまったく別の方法はありますか?
どうもありがとう。