Fringe81 Advent Calendar 2018の24日目、本日はクリスマスイブですね！
秋に調査していたマイクロフロントエンド(Micro frontends)について書きます。
マイクロフロントエンドとは
[翻訳記事]マイクロフロントエンド マイクロサービスのフロントエンドへの応用でサンプルアプリケーションを交えて詳しく書かれています。
詳細はそちらに任せて、ここでは僕が大事だと思ったポイントだけ述べます。
マイクロサービスをフロントエンドまで拡張した考え方
近年SPAによって、フロントエンドとサーバサイドを切り分けて開発できるようになりました。
しかしプロダクトが成長すると分離したアプリケーションも肥大化し複雑化します。
そうすると、品質を担保したり生産性を上げることが困難になってきます。
分離してもしなくても抱える問題は変わらないですね。
そんな中でサーバサイドではマイクロサービスの考えで解決するのが、一つの手段として広まりつつあります。
勉強会やカンファレンス等に行っても、実際にマイクロサービスの事例が増えてきている実感があります。
一方フロントエンドではどうでしょうか？
SPAをどう実現するかのFWの話は多いのですが、設計論的なところの話はちょっと寂しいですね。
肥大化し複雑化するフロントエンドアプリケーションを解決する一つの可能性として考えられているのが、マイクロフロントエンドです。
マイクロフロントエンドは、__マイクロサービスで切り分けした各々のサービスに対してフロントエンド、つまりUIも含めてしまおうという考え方__です。
つまり、マイクロサービス化して構成した各チームにフロントも含めることになります。
モノリシックなSPAがサービス毎の部品の集合体になりそうな感じがしてきませんか？
技術的側面
SPAがサービス毎の部品の集合体になるということは、どのように実現することになるのかを考えていきます。
マイクロサービスではサービス毎に切り出すことができると各サービスは疎結合になるため、IFさえ揃えておけば中の実現技術は何でも良くなります。
あるサービスではGolangを使ったり、別のサービスではScalaを使ったり。IFだけはRESTやGraphQL等で揃えます。
マイクロフロントエンドも同様なことが実現できます。それが出来ないと魅力半減ですからね。
マイクロフロントエンドでは__Custom Elements__をIFとして使い、実装技術を隠蔽化してしまいます。
__DOM is API__と考えられているようです。
これにより、例えば以下のようにすることができます。
- AチームではReact
- BチームではElm
- CチームではElm
各チームが開発したアプリケーションを、Custom Elementsで統合して1つのアプリケーションにするという感じになります。
ここではCustom Elementsの詳細については触れませんので、知りたい方は別途調べてください。
各チームが独立しているため実装技術の分離ができます。疎結合ってやつです。
例ではBチーム・CチームがElmで同じ技術を使っていますが、疎結合を保つためにコードの共有もNGと考えられています。
もちろん状態もです。あくまで疎結合に拘ります。
こうなっていれば、各チームは実装技術を独立して選ぶことができるし、独立してデプロイも可能な感じがしてきますね。
このあたりの話が、最初に挙げた__[翻訳記事]マイクロフロントエンド マイクロサービスのフロントエンドへの応用__の中のマイクロフロントエンドの根底にある考えに書いてあります。
なぜマイクロフロントエンドを調査したのか
ここでそもそもなぜマイクロフロントエンドを調査したのかを書いていきます。
調査の理由は、__プロダクトが成長してきてアプリケーションが肥大化し複雑化しつつある中で、品質を担保したり生産性を上げるための打ち手がないか__です。
これだけだとちょっとバクっとしているのでもうちょっと具体的なモノに落とてみます。
モノリシックなアプリケーションであるという前提での話です。
- 歪みが生まれないようにレビュー頑張る
- どうしても歪になってしまうところを、時間かけて頑張って最適解を探してしまう
- 人数増えるとレビュアーのレビュー負荷が増える
- 新規JOINしてきた開発者にも初めからそれなりの実装品質を求めてしまう
- ライブラリアップデートがアプリケーション全体になってしまって、影響範囲調査やリグレッションテストでコストかかる
プロダクトの規模が大きくなったときにありえそうなことだと思います。
成長しているプロダクトはやっぱりスピード感ある価値提供が大事です。
上記に対して打ち手を考えておかないと、品質のためにスピード感が失われる可能性があり、スピード感のために品質が失われていく可能性があります。
どちらも頑張ってやりきれず、結局巨大な泥団子ができてしまったなんてのはやりたくないですよね。
フロントエンドでも品質を各チームで担保できる仕組みがないかを探していました。
そういう仕組があれば、例えばあるチームの実装が腐ってきてどうにもならなくなったので作り直しします！となっても、モノリシックなアプリケーションよりもイージーにできそうな感じがしますよね。
マイクロフロントエンドは導入できるのか？
私見ですが、マイクロフロントエンドを導入するのには以下が必要だと考えています。
特定の領域やミッションに特化したチーム構成になっているか、またはチーム構成にすることができるか
上記ができるのは、ある程度のドメインが見えていて開発の人数規模もそれなりの数になっていないと難しいと思います。
新規プロダクトや発展途上のプロダクトでは、ドメインが定まっていないと思うのでチーム化は難しそうです。
技術ドリブンで選定してしまった場合には、チームと実装にズレが発生した時の軌道修正が大変そうです。
少数の場合には、複数のチームにエンジニアは所属することになりチーム間で共通実装が使えないとかは辛そうです。
ある程度の規模感になった時に少しづつ剥がして適用していくのが良さそうな感じがしています。
その時のために、疎結合と高凝集を意識した作りにしておくことは大事ですね。
まとめ
マイクロフロントエンドはまだ試行錯誤の段階で実績も多くはありませんが、肥大化・複雑化していくアプリケーションに対する一つの手段になる可能性があります。
興味を持った方はぜひ最初に挙げたリンク先でサンプルコードも見てください！
フロントエンドの世界では今後、設計・アーキテクチャなところが活発化していくんじゃないかと考えています。