4

バックグラウンド：

私は、少なくとも 1 日に 1 回、本番環境にデプロイされる単一ページの JavaScript Web サイトを持っています。それは妥当な量のトラフィックを取得し、ユーザーがチェックアウトして JavaScript が XHR を介してバックエンドと対話するまで、かなりの時間そこにとどまります。

問題：

デプロイ後、ブラウザーにロードされた JavaScript はバックエンド (この場合は Rails) と互換性がなくなる場合があります。

可能な解決策：

a)定期的にアセット パイプラインのフィンガープリントを比較し、window.confirm とリロード リクエストが同じでない場合は比較します。

b) XHR リクエストで X-JS-fingerprint ヘッダーを送信します。互換性がない場合は、409 Conflict が返され、JavaScript によってエラーがトリガーされ、window.confirm がリロードされます。

c) 2 つのバックエンドを実行します。1 つは新しい JS と新しいバックエンド コード(SERVER-1)ですぐに展開され、もう 1 つは古い JavaScript XHR 要求形式を引き続きサポートします(SERVER-2)。b)と同様に、X-JS-fingerprint ヘッダーが送信されますが、409 の代わりに 307 一時リダイレクトが SERVER-2 に送信され、要求が完了します。古いセッションがすべてクリアされると、SERVER-2 が展開され、再び必要になるまでシャットダウンされます。

誰かがこの問題について以前に考えたことがあるなら、私は興味があります。この件についてご意見がありましたら、お知らせください。

4

2 に答える 2

2

私もこの問題に遭遇しました。私の解決策は非常に単純で、実際にはユーザーのエラーを回避しようとはしていません。それはあなたのソリューションaに似ています。

フィンガープリントのようにバージョン番号を保持します (すべてのファイルも同様にフィンガープリントされます。CSS/JS)。デプロイ プロセスでは、バージョン番号が自動的に増分されます。CSS を 1 行変更しただけでも、バージョン番号がインクリメントされます。バージョンのメジャー変更とマイナー変更を区別していません。これはセマンティクスにすぎません。

アプリケーションはサーバーに頻繁に ping を送信してバージョンを確認します。バージョンが変わると、「ページをリロードしてください」というポップアップが表示されます。(ページの上部にある邪魔にならない小さなもので、非常に目につきやすく、クリックする必要があります)。ユーザーがリロードしないとエラーが発生する可能性があるため、バージョンが一致しない場合はエラー報告も無効にします。

このソリューションは、最終的に人々が新しいバージョンに切り替えることを保証するだけであり、ユーザーが切り替えている間にエラーが発生することはありません. 古いセッションを移行したり、ユーザーのエラーを防止したりすることはありません。

私はしませんwindow.confirm。予期しないモーダル ダイアログは非常に煩わしいものです。たまたま何かを入力しているときに を押す[space-bar]か[enter]、ダイアログが消えて見逃した場合。

解決策bは良さそうに見えるかもしれませんが、裏返しがあります。バージョンの不一致を早期に検出できますが、ユーザーがより多くのエラーを目にする可能性もあります。Web サイトのごく一部のみが更新の影響を受けた場合、XHR 要求は失敗する必要がなくても失敗します。それは考慮すべきことです。

解決策cはユーザーにとっては非常に便利ですが、アップグレードは地獄になるかもしれません。データベース モデルが変更された場合はどうなりますか? 古いサーバーはデータを適切に操作できず、クエリは失敗します。

ソリューションa は非常にシンプルで、小さな変更を頻繁に更新する場合、各更新の影響が非常に小さいため、ソリューション a が気に入っています。

于 2013-06-24T16:52:05.107 に答える