モノリスをどのように見たか。パート2、フレームマネージャー

こんにちは、私の名前はスタスです。ティンコフビジネスチームで働いています。前回の記事で、同僚のVanyaがアプリケーションアーキテクチャの配置方法について説明しました。Vanyaは、アプリケーションオーケストレーターとして機能する特定のフレームマネージャーについて何度か言及しましたが、それについて詳しく説明します。

ティンコフビジネスとは

Tinkoff Businessは、中小企業向けのソリューションを提供しています。給与プロジェクト、現金および決済サービス、ドキュメントデザイナー、その他約20の製品です。

これはすべてアプリケーションに実装されています。これらのアプリケーションは別々のチームによって開発され、独自のリリースサイクルがあります。そして、これらのアプリケーションはすべて、単一の認証で動作し、ビジネスロジックの共通部分を別のライブラリに含み、共通のUIコンポーネントを使用します。

2年前に戻りましょう

典型的なTinkoffBusinessアプリケーションは、次のようになりました。







上-アプリケーションをナビゲートするヘッダー、右側-製品ナビゲーションを含むサイドバー。

当時、マイクロフロントのアイデアはまだそれほど人気が​​ありませんでしたが、私たちはすでにこの方向に進んでいました：サイドバーは別のAngularアプリケーションでした。メインアプリケーションはサイドバーをiframeにロードしました。これにより、アプリケーションを個別にリリースできました。



このアプローチには欠点がありました。製品を切り替えるときに、2つのAngularアプリケーションでページ全体が読み込まれるのを待つ必要がありました。また、ほとんどのアプリケーションは同じバックエンドAPI要求を使用するため、ユーザーはそれらが再実行されるのを待つ必要がありました。

フレームマネージャーのアイデア

すべてのアプリケーションのグローバルタスクが出現するまで、私たちはそのようなアーキテクチャを使用していました-再設計。次に、アイデアが浮かびました。ある種の制御の反転を実行して、アプリケーションがサイドバーを内部にロードする代わりに、サイドバーがアプリケーション自体をロードするのはなぜでしょうか。



これにより、現在のアーキテクチャの利点を維持し、上記の問題を取り除くことができました（そして新しい問題をもたらすことができました、ハハ）。

初期プロトタイプ

最初に、他のアプリケーションをロードするために必要な最小限の機能を備えたプロトタイプを作成しました。別のドメインがテストベンチに作成されました。アプリケーション統計のnginxのルートが変更されました。以前は、対応するアプリケーションの統計がパス/ sme、/ account、/ salaryなどに沿ってロードされていました。これで、Frame Managerの統計情報がすべてのパスに沿って送信され、アプリケーション自体の静的ルートに接尾辞/静的情報が追加されました。



明確にするために、例を見てみましょう。/some-appパスにあるアプリケーションをsome-routeでロードする必要があります。詳細はさておき、/ some-app / some-route /をロードするときにどのようなプロセスが発生するかを見てみましょう。

1. Nginxは、このパスに沿ってFrameManagerの統計情報を送信します。
2. フレームマネージャーを読み込んでいます。ルートに基づいて、彼はいくつかのアプリをダウンロードすることを理解しています。
3. iframeは、メインアプリがロードされるsrc = '/ some-app / static /'で作成されます。

同時に、アプリケーション自体に大幅な改善が必要でした。そのため、アプリケーションブランチのマスターをフォークし、そこに必要な変更を追加した後、変更を加えてアプリケーション自体の個別のコピーを作成しました。

最初の問題

そこで、4つのアプリケーションをFrame Managerに転送し、ソリューションが機能していることを確認しました。他のすべてのアプリケーションは翻訳されることになっていた。そして、ここで問題が発生しました。通常のバージョンとFrameManagerで動作するバージョンを同時に維持するにはコストがかかりすぎることが判明しました。



古いバージョンのマスターに変更するたびに、アプリケーションの新しいバージョンを絶えず更新し、新たな競合を解決し、既存の機能が頻繁に壊れ、回帰テストのコストがほぼ2倍になる必要がありました。これにはすべて時間がかかりすぎました。新しい解決策が必要であることは明らかでした。

改善点

アプリの1つのバージョンがサイドバーとフレームマネージャーの両方で機能する場合、それは私たちに多くの問題を救うでしょう。何ができるか見てみましょう。



まず、アプリケーションがフレームマネージャーで実行されているかどうかを何らかの方法で判断する必要があります。これは非常に簡単です。window.topとwindow.selfの参照を比較する必要があります。それらが等しくない場合、フレーム内、つまりフレームマネージャー内にいます。ただし、デフォルトでiframeで開くアプリケーションがある場合は、ロジックを追加する必要があります。そのため、最初にフレームで開いたウィジェットアプリケーションがあり、それが常にフレームマネージャーにあると想定し始めたため、古いモードで機能しなくなりました。



次に、アプリケーションで必要な変更と、2つのモードでの作業をサポートする方法を詳しく見ていきましょう。

1. url. iframe, . , - , — . url’ Frame Manager, . .
   
   
2. . Frame Manager’ . : . . , , , post messages custom events. Frame Manager.
   
   
3. . , Frame Manager. , Angular .
   
   
4. . , , TCS, config.js . Frame Manager .
   
   
5. base href. nginx, base href ( /static/). : , base href , . , , , , base href, .
   
   
6. 承認。すべてのアプリケーションでの承認には、index.htmlに埋め込まれている個別のスクリプトが使用されます。新しいバージョンでは、このスクリプトはフレームマネージャーに埋め込まれており、アプリケーションで再利用するとエラーが発生します。スクリプトロジックを変更して、アプリケーションがフレームマネージャー内にロードされた場合に無視されるようにすることができます。
   
   

これらはすべて実用的なソリューションですが、十分な柔軟性がありません。新しいブランチにロジックが追加されましたが、これもさまざまな場所で維持する必要があります。一般に、すべてが複雑すぎてかなり不安定な構造のように見えます。

iframeの再発明

次に、index.htmlアプリケーションをロードするプロセスを少しハックするというアイデアを思いつきました。 src属性を指定してアプリケーションをiframeにロードする代わりに、index.htmlに対してxhr要求を行い、ページをテキスト形式で取得して処理し、iframeにロードすることができます。これにより、ロードされたアプリケーションを完全に制御できます。ベースhrefの定義、不要なスクリプトの削除、スタイルのパッチ、変数のオーバーライドなどが可能になります。



はい、mokeyパッチは開発者によって推奨されておらず、悪い習慣と見なされていますが、Angularチームがzone.jsライブラリでそれを使用する場合、どのように悪化しますか？パフォーマンスの問題が発生する可能性があります。htmlの解析はコストのかかる操作のように見えます。ただし、原則として、Angularアプリケーションの開始ページは50行を超えず、すべてのブラウザー（IE 10でも！）には便利なapiがあります。DOMParser。文字列からDOMを取得できます。



アプリケーションのロード中にフレームマネージャーが何をするかを見てみましょう（フレームマネージャー自体はすでにロードされています）。

1. パスに基づいて、アプリケーションのindex.htmlをロードします。
   
   
2. ページを解析してDOMに変換し、メモリ内の不要なスクリプトを削除し、ベースのhref、グローバル変数を構成とスタイルに置き換えます。
   
   
3. document.write（）を使用して、結果のドキュメントを書き込む（文字列に変換して戻す）iframe要素を作成します。
4. アプリケーションを配線先のルートにします。また、ビジネスロジックがデータ交換サービスを介して機能するために必要なモデルを提供します。
   
   

したがって、ロジックで必要な上記の6つの変更のうち、最初の（url同期）のみをアプリケーション内に実装する必要があり、残りはフレームマネージャーが処理します。

何を得た

アプリケーション自体のコードを実質的に変更することなく、アプリケーションの外観を完全に変更しました。





グローバル変数とスタイルをオーバーライドまたは追加する機能を取得しました。





同時に、構成はフレームマネージャーとは別のリポジトリにあり、リリースせずにアプリケーションの作業の一部のパラメーターを変更できます。



また、アプリケーション間のシームレスな移行を作成し、FrameManagerで認証を行いました。フレームマネージャとアプリケーション間のデータ共有により、不要なリクエストが行われないようにしています。



問題がないわけではありません。対話中にウィンドウへのリンクが失われたため、一部のchromeプラグイン（CryptoPro、redux devtools）がダウンロード可能なアプリケーションで機能しなくなりました。追加の改善が必要でした。



その結果、2019年の終わりに、すべてのアプリケーションをFrame Managerに正常に転送し、サイドバーは忘れ去られました。しかし、フレームマネージャーの作業は継続され、新しい疑問が生じました。TinkoffBusinessのフロントエンドの作業を何らかの方法で改善および最適化することは可能ですか？あなたができることが判明しました！しかし、それについては次の記事で詳しく説明します。