Luca Mezzaliraでポッドキャストエピソード6を壊す：マイクロフロントエンドとは何ですか？

公開: 2022-03-10

簡単な要約↬SmashingPodcastのこのエピソードでは、マイクロフロントエンドについて話します。マイクロフロントエンドとは何ですか？それは、現在私たちが取っているようなアプローチとどのように異なりますか？マイクロフロントエンドのパイオニアであるLucaMezzaliraから見つけました。

今年はさらに別のSmashingポッドキャストで締めくくります。今回は、マイクロフロントエンドについて説明します。マイクロフロントエンドとは何ですか？私たちが現在取っているようなアプローチとはどう違うのですか？マイクロフロントエンドのパイオニアであるLucaMezzaliraから調べてみましょう。

メモを表示

毎週の更新

「JAMstackサイトへの動的および非同期機能の追加」、Jason Lengstorf
「UXデザイナー向けの定量的データツール」、Adonis Raduca
「GoogleアシスタントとAmazonAlexaの音声スキルの作成」TrisTolliday
「スプリント0を超えて：チームを統合するための代替手段」、Shamsi Brinn
「CSSContainプロパティを使用してブラウザを最適化するのを支援する」RachelAndrew

マイクロフロントエンド

LucaMezzaliraのウェブサイト
Twitterのルカ
中規模の「マイクロフロントエンド、フロントエンドアーキテクチャの未来」
マイクロフロントエンドに関するLucaの執筆の詳細は、彼のMediumアカウントにあります。
Lucaの本「Front-EndReactiveArchitectures」

トランスクリプト

ルカメザリラの写真 Drew McLellan：彼は、ウェブテクノロジーに関するGoogle開発者の専門家であり、ロンドンのJavaScriptコミュニティのマネージャーです。 15年以上の経験を持つ彼は、現在、建築担当副社長として、スポーツビデオプラットフォームDAZNを設計しています。このプラットフォームは、ライブで視聴している何百万人ものユーザーにオンデマンドのスポーツコンテンツを配信しています。彼は、『Front-End Reactive Architectures for Apress』の著者であり、Apress、Packt Publishing、Pragmatic Bookshelf、およびO'Reillyの技術レビュー担当者であり、世界中の技術会議で経験豊富な講演者でもあります。彼はイタリア人で、ハンサムなあごひげを生やしていて、明らかにWebプラットフォームに関する深い知識を持っています。しかし、彼がかつてダチョウで南アメリカを横断したことを知っていましたか？私の壊滅的な友人、ルカメザリラを歓迎してください。こんにちは、ルカ。元気ですか？

Luca Mezzalira：私は粉砕しています。

ドリュー：今日はマイクロフロントエンドのテーマについてお話ししたいと思います。さて、これは確かに名前で私にとって全く新しい概念であり、私はそれが私たちの多くのリスナーにとっても新しいことを期待しています。マイクロフロントエンド自体に入る前に、マイクロフロントエンドで対処しようとしている問題を理解する必要があると思います。それで、おそらく、より伝統的な方法でアプリケーションをどのように見ているか、そしておそらくマイクロフロントエンドが解決策になるかもしれないそれらの問題がどのような問題にぶつかるかについて少し教えていただけますか？

ルカ：そうですね、それは私の意見では良い出発点です。したがって、通常、新しいグリーンフィールドプロジェクトを実装または設計し、フロントエンドアプリケーションを操作する場合は、活用できるアーキテクチャがいくつかあります。シングルページアプリケーションを使用することも、サーバー側のレンダリングアプリケーションを使用することも、単純なHTMLページだけで構成されるマルチページアプリケーションを使用することもできます。明らかに、これらは非常に有効なオプションであり、多くの開発者によって非常に使用されていると思います。ここで解決しようとしている本当の問題は、分散したチームでこれらの概念を同じコードベースで作業する数百人の開発者に拡張する方法です。現実は、特にこれらのプラットフォームで作業しているときです。たとえば、SaaSプラットフォームでは、同じプロジェクトに取り組んでいる複数の開発者と複数のチームが必要です。そして明らかに、たとえば、取得や保持を行う方法は、カタログを公開する方法やプラットフォームの特定の部分を表示する方法によって完全に異なります。

Luca：それで、今の私の経験では、シングルページアプリケーションで多くのことをしています。私はサーバー側のレンダリングアプリケーションを使用していますが、DAZNのある時点で、技術チームを拡張する方法について考えるように求められます。そして、私は考え出す必要があります…この場合、バックエンドにマイクロサービスであるソリューションがある場合、APIを個別にスケーリングし、特定のAPIの特定のスループットのスケールとボリュームを考慮することができます。フロントエンドでは、実際にはもっと難しいのです。なぜなら、それについて考えると、たとえばシングルページアプリケーションを使用している場合など、スケーリングが必要なときに解決する技術的な問題がないからです。おそらくサーバー側のレンダリングにはいくつかありますが、たとえば、単一ページのアプリケーションでは、クライアント側と異なるクライアント側にあるため、本質的に分散されます。

Luca：ロードしているのは、CDNによって提供されるCSS、HTML、JavaScriptなどの静的ファイルだけです。その場合、それに応じてスケーリングできるので、大きな課題ではありません。ただし、実際の課題は、同じプラットフォームで作業するチームをどのようにスケーリングするかです。これは、あるチームが直面する課題が別のチームが直面する課題とは完全に異なる場合があるためです。通常、あなたが行うことは、見つけようとすることです。物事の間の多くのトレードオフ。なぜなら、あなたが考えるなら、通常のユースケースを考えてみましょう。したがって、通常、プラットフォームを開始するときは、小規模から開始します。つまり、モノリスを持っているだけでなく、そのクイックシングルページアプリケーションを作成しようとするので、フロントエンドとバックエンドに対してCICDのすべてを一度だけセットアップしてから、ロジックの反復を開始します。しかし、現実には、成功した場合、この部分を進化させる必要があります。たとえば、ボトルネックが見つかる可能性があるため、ビジネスにメリットをもたらす可能性のある同じアーキテクチャを常に維持しているとは限りません。

Luca：では、シングルページアプリケーションの部分に戻りましょう。したがって、単一ページのアプリケーションパーツをスケーリングする場合、課題は技術的なものではなく、必要に応じて人間が行うことになります。では、同じアプリケーションで作業するチームをどのように拡張できるか。それで、私が数年前にしたことは、フロントエンドとバックエンドをスケーリングすることを可能にする可能性のあるアーキテクチャと原則を検討し始めたことです。したがって、マイクロサービスを見つけることができるように、バックエンドの原則に取り組んでいます。私は別のソリューションを検討し始めましたが、マイクロフロントエンドが出てきました。最初はそのように呼んでいませんでした。明らかに何年も前には、その特定のアーキテクチャの名前がなかったからです。。

Luca：しかし、現実は一枚岩を採用しているので、単一ページのアプリケーションを、小さな問題に集中できるようにスライスします。したがって、アプリケーション全体よりも小さな問題であり、可能な限り最善の方法でそれを解決しようとしています。技術的に言えば。明らかに、他のすべてに影響を与えることなく本番環境にデプロイできるフロントエンドアプリケーションの独立した部分を持つことになります。したがって、基本的にマイクロフロントエンドの課題は、シングルページアプリケーションまたはサーバー側でレンダリングされたアプリケーションを取得し、これらのアーティファクトを作成する方法を見つけようとすることです。たとえば、ビジネスドメインにできるだけ近く、独立して展開できます。。

ドリュー：つまり、バックエンドのマイクロサービスについて言及されたということです。したがって、概念的には、これは問題に対する同様の解決策です。マイクロサービスはバックエンドで機能しますが、フロントエンドに移植されます。それは大まかな同等性ですか、それとももっと関与していますか？

ルカ：はい。いいえ、これは、バックエンドでマイクロサービスを解決しようとしているのと同じ問題を解決する方法ですが、今回はフロントエンドで解決します。通常、私が最初にこの旅を始めたとき、あなたはそれについて考え始め、さまざまなアプローチを評価し始めます。そして、ここ数か月で、彼らが呼んでいるマイクロフロントエンドの意思決定フレームワークを思いつきました。これは、基本的に、マイクロフロントエンドのアプローチを特定するために使用する4つのステップです。通常、私たちのためにアーキテクチャを設計した1つのフレームワークを選択し、それらのアーキテクチャの上に実装します。 Angularについて考えたり、ReactやReduxについて考えたりする場合。必要なものはすべて揃っていますが、アーキテクチャ上の決定は行いません。設計上の決定を行うか、その特定のアーキテクチャの上にどのように実装するかを決定します。

ルカ：マイクロフロントエンドでは、ステップバックを開始する必要があります。したがって、最初にアプリケーションをどのようにスライスするかを考える必要があります。したがって、通常は2つのオプションがあります。水平方向にスライスできるため、同じビューに複数のマイクロフロントエンドを配置することも、垂直方向にスライスすることもできます。したがって、常に1回に1つのマイクロフロントエンドをロードします。そして、これらの決定は非常に重要です。それは、最初の決定に基づいて、他の特定のオプションをカスケードするためです。したがって、最初に、私が言ったように、アプリケーションをどのようにスライスするかを決定します。 2つ目は、アプリケーションをどのように構成するかです。たとえば、同じビューに1つまたは複数のマイクロフロントエンドを読み込んでいるアプリシェルのようなものが必要です。アプリケーションのさまざまなフラグメントを構成しているアプリケーションサーバー、つまりさまざまなマイクロフロントエンドを使用して、ユーザーに最終的なビューを提供する必要があります。または、含まれているエッジサイドを使用したい場合は、ページを構成してそこで提供するためにCDN内にある標準です。

ルカ：これらはあなたが持っているオプションの3つです。そして、作曲とは別に、どのようにルーティングしたいかを考える必要があります。したがって、/ loginまたは/ signinからカタログパーツまたは特定の詳細オブジェクトにどのようにルーティングするかはわかりません。また、ここには3つのオプションがあります。アプリケーションサーバーでそれを行うことができます。LambdaEdgeまたはCloudFlareの他のWebワーカーまたはその他のものを使用してCDNレベルで行うことができます。または、クライアントサイトを作成することもできます。つまり、アプリシェル内にロジックがあり、この特定のURLに対して、別のビューまたは別のマイクロフロントエンドをロードする必要があります。そして最後のビットは、マイクロフロントエンドとの通信方法です。

Luca：通常、同じページに複数のマイクロフロントエンドがある場合、異なるマイクロフロントエンドを独立して維持する必要があるため、この通信の管理はより複雑になります。つまり、ページがどのように構成されているかを参照することはできません。したがって、通常は、カスタムイベントや各単一のマイクロフロントエンド内に挿入されるイベントメーターなどを使用できます。そして、マイクロフロントエンドは相互に通信しています。明らかに、他のケースでは、マイクロフロントエンドを垂直方向に分割する方がはるかに簡単です。垂直方向の内部では、基本的に垂直方向のマイクロフロントエンドの表現は単一ページアプリケーションまたは単一ページであるためです。その場合、マイクロフロントエンド全体で共有状態を持つ作成と共有を行う方が簡単です。

Luca：次に、複数のマイクロフロントエンドをすべて一緒に使用することを検討している場合は、マイクロフロントエンド全体で状態を共有することは避けてください。そうしないと、物事を結合していることになります。ここでの全体的な概念の代わりに、デカップリングと独立した展開があります。したがって、最初に行うべき決定である水平分割または垂直分割の課題は完全に異なり、どちらがユースケースに適合するかを十分に認識する必要があるとしましょう。

ドリュー：つまり、マイクロフロントエンドは、特定の技術的ソリューションというよりも、解決しようとしている特定の問題に適したテクノロジーに実装するデザインパターンに非常によく似ていますか？

Luca：ええ、テクノロジー以上に、適切な仕事に適切なアーキテクチャを選択していることがわかります。例を挙げると、私は話していました…有名なフレームワークがあります。これは、Micro-frontendにとってはかなり新しいもので、Luigiフレームワークと呼ばれ、SAPオープンソースによってリリースされました。彼らが行っているのは、マイクロフロントエンドをその中にラップしているいくつかのiframeを作成することです。ですから、それについて考えると、たとえば、最近iframeを使用している場合、SEOやその他の必須機能として、問題が発生する可能性のある公開Webサイトにアクセスしているとします。

Luca：しかし、SAPの場合、考えてみれば、ユーザーが使用しているブラウザーを制御したり、環境を制御したりできるエンタープライズアプリケーションのようなものがあり、多数のユーザーが利用できる必要はありません。ブラウザの異なるバージョン。したがって、これらのことにより、アプリケーションの特定の領域が一定であり、問題なく独立して変化する特定の領域を持つことができます。しかし、明らかにiframeソリューションは他の状況では機能しません。別の例として、Spotifyを例にとると、最初はiframeを使用しています。実際、デスクの出版物はまだ複数のiframeで構成されており、各iframeは小さなアプリケーションであり、音楽プレーヤーやその推奨事項が何であれ、それを実行します。彼らはWebでも同じアプローチをとろうとしていますが、今年はシングルページアプリケーションに戻すためにそれを却下しました。

Luca：つまり、技術ブログで、同じベンダーがファイルするたびにロードする必要があるiframeを使用している何百万ものユーザーにそれを適用すると明らかに言っていたのです。そして、多くの依存関係が複製され、ページを操作する時間が長くなります。したがって、実際には、このアプローチは特定のユースケースに適合する可能性がありますが、すべてに適合するわけではありません。そのため、前に説明したように、これらの問題に対処するのに役立つ意思決定フレームワークがあり、このようにアプリケーションをスライスしたので、利用可能なオプションがあります。作曲したいとき、ルーティングしたいとき、コミュニケーションしたいとき、それは適切なタイミングで適切な決定を下すためにあなたを導くはずです。

ルカ：それでは、明らかにこれらの4つの決定とは別に、他にも多くの決定があります。すべてのマイクロフロントエンドで使用している設計システムに一貫性を持たせる方法と同じです。または、依存関係を管理し、マイクロフロントエンド内での依存関係の衝突を回避する方法がわかりませんが、実際には、前述の4つの決定により、他のすべての決定をすばやく行うことができます。考えすぎの問題。これは、他のすべての決定を下すことができる4つの柱である基礎をすでに設定しているため、最善の解決策です。簡単な方法ではありませんが、レビューよりも迅速な方法で言います。または機会のスペクトル。

ドリュー：前に述べたように、マイクロフロントエンドが組織内のチームの構造のようなものを支援し、多くの人々が同じアプリケーションで作業する方法を支援します。その場合の影響にはどのようなものがありますか。また、チームが分散しているか、同じ場所に配置されている場合、またはそこで直面している課題がある場合、違いはありますか？

ルカ：はい。だから私はあなたにDAZNの物語が何であるかを言うことができます。それが私が取り組んでいる会社です。現在DAZNで、私たちは素晴らしい挑戦が好きでした。そのため、現在、プラットフォームのフロントエンドとバックエンドで作業している300人以上の人がいます。これは、世界中のスポーツイベントでライブストリーミングを行っているOTTプラットフォームです。そして興味深いのは、すべてのマイクロサービスが多かれ少なかれ管理する方法を知っていて、チームを分散させているかどうかです。つまり、4つの開発センターがあります。チームを各開発センターの前面に配置したいので、このアプローチを試しましたが、かなりうまく機能しました。そのため、マイクロフロントエンドを使用すると、さまざまな場所にさまざまなビジネスドメインを提供し、特定のビジネスドメイン内のチーム間の相互通信を可能にすることができました。これは、同じビジネスドメインの別のチームと話す必要がある場合の最悪のシナリオであるためです。、あなたはちょうどあなたの机から徒歩圏内に到達します。代わりに、配布チームで特定のことについて話し合う必要がある場合は、アムステルダムの代わりにロンドンの誰か、またはポーランドの会社の代わりに、電話をかけるだけです。

ルカ：しかし、そのような種類のコミュニケーションは、同じ場所内のチーム間で行われているものよりもまれです。そしてそれが私たちがそれに取り組み始めた理由です。したがって、彼らが最初に行ったのは、ユーザーがWebサイトをどのように操作しているか、会社がどのように構成されているかを確認することでした。そして、私たちが取り組んでいる4つの主要な領域、つまり現在取得と保持を特定するとき、それらのコアアプリケーションを複数のテレビとモバイルに移植し、私たちにとってビデオプレーヤーとの発見段階であるコアドメインを持っているとしましょう。私たちのコンテンツ。そして最後に、すべてのバックオフィス要素。私はそれらの4つの領域を特定することができ、それぞれの単一の開発センターに割り当てた4つの領域を特定することができました。

Luca：明らかに、これらの領域間にはいくつかの接点がありますが、たとえば、さまざまな場所にあるさまざまなチームとの最初のワークショップを緩和して行い、同じAPI契約に向けて取り組む方法があります。開発中にいくつかのチェックポイントを持つという同じ目標。しかし、マイクロフロントエンドでのアプローチを可能にしたアプローチの良い点は、システムがどのように機能しているかを最終的に深く理解したという事実です。私たちは座って、自分たちがどのように構成されているかを分析し、影響を受けた方法だけでなく、会社の働き方も変えました。そして、それは彼らがこれまでに見たものとは一種の異なるアプローチでした。しかし、各チームが同じドメイン内の同じ場所のチームと対話できる場合は、それが非常にうまく機能していることが証明されています。

ルカ：つまり、ドメイン駆動設計について話しているのであれば、彼らはまったく同じ言語で話しているのです。つまり、他のチームとやり取りする必要がある場合は、文字通りワークショップを共有したり、別の開発センターに飛んだりすることができ、問題はありません。しかし、このようにして、スループットを向上させ、通信のオーバーヘッドを減らし、他の状況で発生していた依存関係の範囲を減らします。

ドリュー：そして、これらすべてのチームは、標準化されたJavaScriptフレームワークのように使用する必要がありますか？それらはすべて同じものでコーディングする必要がありますか、それらはすべてReactまたはAngularである必要がありますか、またはそれらの間の相互運用性を有効にする必要がありますか、または人々は異なるマイクロフロントエンドに異なるものを使用できますか？

ルカ：うん。そのため、DAZNでは、マイクロフロントエンドを垂直にスライスすることにしました。これにより、各マイクロフロントエンドに必要なテクノロジーを自由に選択できるようになりました。毎回1つのマイクロフロントエンドをロードするたびに、これは、たとえば、ランディングページの作成方法が、サインイン/サインアップの過程とは異なることを意味します。だから私たちは更新することができます…私たちは現在主にReactを使用しています。しかし、たとえば、React16が本番環境のReact16でリリースできたリリースだったとき、それがランディングページだけの安定したバージョンではなかった場合、すべてに影響を与えることなく機能していたかどうかを確認します。他のチーム。

ルカ：そして、彼らは自分たちのスピードで、自分たちのペースで、自分たちのものを更新していました。これにより、特定の数のユーザーを使用して、既存のアプリケーションにある新しいテクノロジーや新しい仮定を試すこともできます。フロントエンドの候補リリースも実装しているためです。私たちは、本番環境で特定の時間を試して、物事がどのように機能しているかを確認できるようにするいくつかのプラクティスを実装します。

ルカ：これらのアプローチの美しさは、スタック全体に共通の分母を持つよりも、適切な仕事に適切なツールを使用することを独自に決定できることです。ご想像のとおり、プロジェクトに取り組み始めたとき、最初の数年間に行った決定は、会社が成長し、ビジネスが進化し、これらがより成熟した軌道で行った決定とはおそらく異なるためです。課題はまったく異なります。ですから、それは十分に柔軟でも機敏でもありません。あなたがそれについて考えるならば、私たちが2年前に行ったのと同じ決定に固執するという事実。特にDAZNのような機関では、3年間で基本的にゼロから3000人の従業員になります。ご想像のとおり、これは大規模な成長であり、企業にとってもユーザーベースにとっても大規模な成長でした。

ドリュー：異なるマイクロフロントエンドがデータを共有し、相互に通信するための確立された方法はありますか？たとえば、同じビューで互いに歩調を合わせるためだけですか、それを行う方法はありますか？

ルカ：はい、あります。それは、どの決定フレームワーク、どのパスを取るかによって異なります。なぜなら、あなたが垂直スライスを取るつもりなら、それは非常に簡単になりました。つまり、Micro-frontendを介して通信するために必要なのは、Micro-frontend自体の内部に読み込まれているアプリシェルです。そして、それが行うことは、たとえば、異なるマイクロフロントエンド間で共有する必要があるすべてのものを、セッションまたはローカルストレージまたはメモリ内のWebストレージに保存することです。そして、それらの情報に基づいて、マイクロフロントエンドが読み込まれ、アプリシェルからこの情報を取得して、それを利用したり、修正したり、変更したりできます。アプリケーションをどのようにスライスするかは完全に異なりますが、この場合、例を示すために、認証されたユーザーであり、サインインページに移動する必要がある場合、ログインするとAPIが消費されます。彼らはJWTトークンを提供しており、Micro-frontendはこれらをアプリシェルに渡し、アプリシェルはこれらを開始してWebストレージを保存しました。

Luca：その後、アプリシェルは、その特定のアプリケーションの新しい認証済み領域とそれらの認証済み領域を読み込んで、アプリシェルからJWTトークンを取得し、アクセストークンの更新を実行するか、内部から始まるデータを検証しています。 JWTトークン。つまり、基本的には、別のマイクロフロントエンドが独自のホイールで生成した情報を使用しています。

ドリュー：それは非常に興味深いコンセプトのように聞こえます。この方法で作業することには多くの大きな利点が見られる可能性がありますが、確かにその課題がないわけではありません。このように物事を設計するときに対処するのがより難しい特定の事柄はありますか？

ルカ：何よりもまず、私が目にする主な課題は考え方の転換だと思います。なぜなら、以前は、たとえば、アプリケーション全体のすべてを決定していた技術リーダーまたはリード開発者がすべての決定を下していたからです。最後に、この集中型エンティティから、各州にローカルな分散型エンティティに移動します。ご想像のとおり、これはいくつかの課題をもたらします。なぜなら、パスをトレースしている人がいる前に、たとえば、ドメイン内の正しいパスを定義する複数の人が上部にいるということです。これは大きな変化です。考え方の。

Luca：一方で、間違った抽象化を行うと、たとえば、コードを複製するよりもコストがかかる可能性があることを複雑に受け入れることがあると思います。開発者が「プロジェクト内でこのオブジェクトまたはこの特定のライブラリを何百回も再利用できるようになりました」と考えているため、開発者の管理に非常に難しいことがあることはわかっていますが、現実は大きく異なります。私は抽象的であるコンポーネントライブラリを見ました、そして彼らはそれをこれまでで最高のコードまたは完璧な形で最高のものとして作るのに多くの時間を費やします。しかし、現実は2回だけ使用されました。ですから、それを行う努力は、正確にはそうではありませんでした。反対側のライブラリでは、特定のコンポーネントのいくつかのユースケースから始まっていることがわかりました。そして、それらのユースケースは10になり、コードは保守できなくなりました。

Luca：したがって、同じコンポーネント内に新しい関数を追加しようとすると、メリットよりもリスクが高くなる可能性があります。したがって、Micro-frontendで理解する必要があるもう一つのことは、それをどれだけ共有したいのか、どれだけ複製したいのかということだと思います。そして、正直なところ、複製しても害はありません。たとえば、私たちの場合、フッターとヘッダーが重複していますが、これは主に、4年間でヘッダーが3倍に変更されたためです。したがって、私たちがこれらを一元化し、チームに割り当てられ、すべてのチーム、つまり私たちが持っている何百人もの開発者すべてに外部依存関係を作成しているという事実を想像できるように、会社にとって利益となる問題はもっと言えます。大きな価値を付加しているわけではありません。

Luca：同時に、現在、支払いライブラリとなる共有ライブラリをリファクタリングしています。これは、明らかに支払いにはその背後にあるロジックがあり、1回変更したい場合は、複数の部分に2回適用したくないためです。コード。信頼できる唯一の情報源であるライブラリが1つだけ必要ですが、ヘッダーとフッターについても、不一致やピクセルがある場合、またはこれが1週間後に展開される関数がある場合でも、問題はありません。申し込み。

ドリュー：それで、アプリケーションを評価して、「ああ、これはマイクロフロントエンドの種類のアーキテクチャに移行するのに良い候補になるだろう」と考えるときに人々が探すべきいくつかの明白な兆候がありますか？

Luca：ええ、私の提案は何よりもまず、Micro-frontendをどのように構築するかを正確に理解していない限り、グリーンフィールドプロジェクトを開始しないことです。特に、新しいプラットフォームや新しいプロジェクトがあり、これに取り組むのが初めての場合は、この情報を見つけるのは簡単ではない可能性があるため、通常、この情報を持っている可能性はほとんどありません。通常、私が提案するのは、シングルページアプリケーションとなる既存のアーキテクチャから始めて、それを進化させることです。特に、たとえば、レガシーアプリケーションにマイクロフロントエンドを使用する場合、アプリケーションの特定の部分を置き換える場合、または複数のチームに合わせて進化および拡張するプロジェクトがある場合、これらは3つのユースケースだと思います。非常に強いと感じているのは、マイクロフロントエンドアーキテクチャに適していると思います。明らかに、それは、マイクロフロントエンドがまったく特効薬ではないため、これからすべてをマイクロフロントエンドにする必要があるという意味ではありません。

Luca：それらは、フロントエンドの世界で活用できる追加のアーキテクチャです。そして今まではある程度のアーキテクチャがありましたが、今では追加のアーキテクチャがあります。ただし、サーバー側のレンダリングやシングルページアプリケーションの前に、いくつかのフレームワークなどによって調査されて実装された明確なパターンがある場合は、明らかにそれが必要になるため、これは多くの課題です。現在マイクロフロントエンドを使用しているのは、物事を行う1つの方法です。しかし、意思決定のフレームワークを追加することで、人々はユースケースに合った正しい意思決定を行えるようになるはずです。マイクロフロントエンドとは何か、そしてそれらをどのように使用すべきかについて、多くの誤解があるためです。そして、多くの人々は、多分、例えば、1つのビューまたは他のことであまりにも多くのライブラリを持っているために悪であると考えています。

ルカ：現実には、概念を深く理解し、それを実装する方法を理解する必要があります。そうすれば、それに取り組むことができます。技術的な課題があり、多くの決定を下さなければならないことに完全に同意します。コードを記述して考えている目の前のエディターからすぐに始めることはできません。今、私はマイクロフロントエンドを作成しています。建築。概念を理解し、コンテキストを理解して作成する必要があるため、その周りのガバナンスも必要です。複雑さはコードを記述するだけではなく、CICD部分、SEO部分などですべての要素がどのように組み合わされているかも理解することです。

ルカ：つまり、マイクロフロントエンドはある程度の柔軟性を提供し、ガバナンスの権利を定義するために多くの努力を必要とします。ガバナンスの権利があれば、すべてがスムーズになるからです。多くの場合、残念ながら私はあまりにも頻繁に言いますが、たとえばCICDを理解しているなど、ガバナンス側で十分な時間を費やしていない企業は、これが重要であるとは考えていないためです。ただし、マイクロサービスのようにマイクロフロントエンドの場合は、自動化を正しく行うことで開発をスピードアップできます。自動化ビットに十分な時間を費やさないと、メリットよりも負担が大きくなるリスクがあります。

Drew： Web開発の世界では、問題を実際に理解する前に、技術的な解決策に飛び込む危険にさらされているようなものがたくさんあると思います。また、マイクロフロントエンドでは、問題を確認してからソリューションを実装して、解決している問題を把握する必要がある場合が非常に多いようです。マイクロフロントエンドの性質上、既存のアプリケーションへの統合を開始し、小さな問題を見つけて、その問題を解決するためにマイクロフロントエンドと交換するのは非常に簡単だと思います。それは合理的な提案ですか？

ルカ：そうだね。この場合、この方法で開始する場合に提案する唯一のことは、水平方向のスライスよりも垂直方向のスライスを詳しく調べることです。そうしないと、多くの問題を解決する必要があるため、たとえばAngularを使用していると仮定します。そして、Angularの新しいバージョンに移行したいとします。 I-frameを使用せずに2つのAngularバージョンを共存させる必要がある場合は、複雑になるか、不可能になる可能性があります。ですから、始めれば、あなたは…からではなく、技術的な観点からではなく、ビジネスの観点から課題をチェックするという側面になります。たとえば、別のバージョンまたは同じバージョンで、フレームワークのより多くの更新バージョンで記述したいサインイン部分を取得することができます。これは良い方法かもしれません。次に、パスを経由します。これは、特定のアプリケーションをゆっくりと、しかし着実に置き換えるための良い方法かもしれません。

Luca：このケースで行ったことは、基本的に、マイクロサービスでよく知られているパターンであるストラングラーパターンをフロントエンドに適用することです。したがって、URLに基づいて、ブラウザとユーザーの国に基づいています。非常にゆっくりですが着実に、基本的にモノリスを殺していました。この場合はシングルページアプリケーションであり、新しいアプリケーションをより頻繁にリリースし、ユーザーの動作を確認しました。エクスペリエンスが向上している場合は、システムに問題が発生していました。か否か。そして、それは私たちがビジネスに即時の価値を提供することを可能にしましたが、同時に私たちの仮定をテストし、私たちが正しい方向に進んでいるかどうかを確認することを可能にしました。

ドリュー：多くの人が直面していると確信しているいくつかの問題に対する非常に魅力的な解決策のように思えます。開発者として、マイクロフロントエンドについてさらに調査を開始したい場合、どこから始めればよいでしょうか。

Luca：はい、そうです。多くの誤解があると思うので、現在、私はこれらのアーキテクチャについて提唱するために多くの余暇を費やしています。私のMediumアカウントで。私はそこでも利用できるいくつかの記事を書きました。 YouTubeで問題なく見つけることができる会議でたくさんのビデオを録画しました。また、いくつかのフレームワークでコード例を探している場合に提案するもう1つのことは、最初に推奨するのは単一のSPAです。これは主に、垂直スライスアプローチを採用しているため、簡単に取得できます。このアーキテクチャの利点を理解し始めることができます。次に、利用可能な他の多くがあります。 Before I mentioned Luigi framework, as well as many others that are currently out there that are allowing you to compose multiple Micro-frontends in the same view.

Luca: Like another one in my head is TailorJS is another interesting. But definitely there is open components that is one developed by Open Table. But in general there are plenty of opportunity if you start to search about Micro-frontend, they're out there.

Drew: That sounds great. Is there anything else that you wanted to talk about with regard to the Micro-frontends?

Luca: Yeah. Personally I would suggest to take an open mind approach on learning this architecture and this approach, technical approach, mainly because I believe that there is a lot of good, but we need to, let's say, invest a bit of time and spend a bit of time to deeply understand how the things are working. Because obviously there isn't, just one way to do things. We are used that we take a framework and immediately we start to work on it and it's super productive, if you think about that.

Luca: But in this case you need to spend a bit of more time understanding, as you said a couple of times, the problem. Understand which is the pattern that would allow you to express better not only from a technical point of view but those two from our organizational point of view, the solution that you have in mind.

Drew: So I've been learning all about Micro-frontend today. What have you been learning about lately?

Luca: Recently there are two things that I'm learning. So last week I was in Las Vegas during the AWS event and is obviously a cloud conference. Pretty amazing, 70,000 people, a lot of sessions that were spreading several hotels in Vegas. And there for me, a serverless is a paradigm that I'm studying the most because I truly believe that in the future that will be the way how we are going to design and implement software and obviously AWS is very prominent on this approach.

Luca: And the second topic is around management and how to be a leader of a tech team. Because obviously I'm SVP of architecture. I have a team of architects that I'm leading and you can never rest because you need to not only to be on top of the technical side, but you need also to understand the people problems, understand how you can make them successful. Because obviously if they are successful, you are successful. You are first a technical facilitator to a certain extent. So that for me, those for me are the two things that currently I'm studying on top of exploring the Micro-frontend world.

Drew: If you, dear listener, would like to hear more from Luca, you can follow him on Twitter where he's @LucaMezzalira or find his activities collected together at Lucamezzalira.com. Thanks for joining us today, Luca. Did you have any parting words?

Luca: No, but thank you very much for listening up to now.