※書きなぐり版なので時間見て清書していきます
主催の @qsona さんによるレポート
オープニング
- 2年目だよ
- 次回テーマは「分断されたモノリス」です
マイクロサービスの利点
- デプロイの分離
- 技術選択の独立
- 組織の分割と自律
- 回復性が高い
- 利用者はマイクロサービスを意識しない
- フロントエンドは統合されていなければならない
- 複数ドメインの統合
- UIテーマの統一
- SPAとかは前提な
- フロントエンドは統合されていなければならない
フロントがモノリシックになると
- デプロイが分離しない
- フロントエンド全体の調整が必要になる
- 技術選択が独立しない
- 基本的には同じフロントエンド技術に縛られる
- 組織が分割できない
- 回復性が高まらない
- フロントエンドがモノリシックなせいでページ全体が落ちる
Micro Frontends の統合
各サービスのUIを統合する必要がある
フロントエンドモノリスの場合
- 各サービスはJSON等のデータをAPIで提供
マイクロフロントエンド
各サービスでフロントエンドUIも含めて構築する
UI、スタイルの共通化が課題になる
第1部 Micro Frontendsの解説 by @nobuhikosawai さん @ FiNC
マイクロフロントエンド、実際に作ってみたらどうなるか。
を解説していきます。
資料はこちら
欲しいもの
- UIコンポーネントの提供
- UIコンポーネント間の強調
- イベントハンドリング
- UIUXの統一
ページ遷移するパターン
- SSO
- UI統一
- ロジックを含むコンポーネント
- 単純なUIパーツ
1つのページに複数コンポーネントを表示
- iframe
- Web Components
iframe
- 各サービスがHTMLを提供
WEb Components
- micro-frontends.orgではCustom Elementsのみ出てくる
サンプルを読み解く
Custom Elementsの定義と呼び出し
- タグはグローバルに宣言されるため、プレフィクスとかで衝突回避
親要素から子要素への通信
- atrribute受け取れるように定義
子から親、兄弟の通信
- イベントで連携
- 独立性高める
その他の観点
UIの統一
- グローバルなCSS
- リファクタリング困難
- npmパッケージ
- Web Components
Routing
- チームをまたぐ遷移をパーシャルレンダリングしにくい
- ルーティングがグローバルな情報になってしまう
第2部 パネルディスカッション: Micro Frontendsの現状と未来
モチベーション
Kaizen Platform
- バックエンドはマイクロサービス化されている
- 個人戦でアプリケーションを作っている状況
- UIとかいい感じに統一したい
- コンポーネントを共通化したい、社内ライブラリとか作り始めた
- マイクロサービスなんだから適したものがあるのでは？
- マイクロフロントエンドとの出会い！
FOLIO
- バックエンドはマイクロサービス化が進んでいる
- レポジトリがたくさん
- バックエンドは小さい単位で開発できてて羨ましい
- フロントエンドは1つでまとめて開発している
- 5人で開発
- 5人の合意取るのが大変
- モノリシックだとフロントエンド製品のライフサイクルに乗りにくい（技術選択）
- レポジトリを小さく分けたい！
サイボウズ
- クラウドサービスのプラットフォーム サイボウズ.com の上にプロダクトが乗っている
- 別のプロダクトが持っている機能を他のプロダクトにも持ってきたい
- でも実はそんなに分けなくてもいいんじゃないか？
パーツ、デザインの共通化、共有の仕方
- 最初は共通のUIを出すことを目指していた
- プロダクトごとに文脈違うから共通化にこだわらなくなった
- 同じ世界感を出すためにUIを共通化することが必要条件だったので、共通部品化がすすんだ（Kaizen）
テクニカルな話
- Web Components使って共通部品化した(Kaizen)
- アイコンコレクション、ヘッダ、メニュー、アバター、アプリケーションタイトル
- アプリケーションの中は触らなかった
- スタイルガイドと異なり、マイクロフロントエンドの場合バックエンドがあることが前提となるのでは
- 契約状態を表すUIなどはバックエンドに依存する
- 「マイクロサービスが提供しろよ！」という欲求が生まれてきた
- 契約状態を表すUIなどはバックエンドに依存する
- バックエンドが提供するフロントエンドのエンドポイントはどうなっている？
- Web ComponentsがWebAPIを叩いてUIを提供する形が理想的
- iframeなんかだと遅いけど、Web Componentsだと解決されるのか？
- 回線富豪になれば解決するのでは
- http/2で解決したりする？
- http/2に夢を見ないのが大事 @teppeis
- モバイルの世界だとまた別の要求があるのでは
- メニューコンポーネントなんかは複数サービスがアグリゲーションされる例
- APIの粒度ってどうだろう
- BFF
- フロントエンドはBFFを叩く、BFFはバックエンドを叩く
- MyPage的なものにマイクロフロントエンドの適用は適さないのではないか
- マイクロフロントエンドを目的化すると死ぬ
- ビジネスドメインに寄ってモデリングが必要
- 1画面にどれだけのドメインが混在しているのか
- 全体としてはそんなに（混在するページは）ないんじゃない？
- ポータル、マイページを除く
- 1画面にどれだけのドメインが混在しているのか
休憩
- マイクロフロントエンドやりたいところはiframe化済みなんじゃないの？
- Google Formみたいなプロダクトはマイクロフロントエンド化するべき
（聞き取れないが休憩中とは名ばかりで議論が盛り上がる）
- (iframeの場合？) イベントは投げれても命令はできない
今日の料理
- 作った方： 管理栄養士（新卒2年目）＋エンジニア（1年目）
- サーモンのマリネ
- 蒸し鶏の梅肉ソース 〜大葉をちらして〜
- 豚しゃぶサラダ
- 夏野菜のミネストローネ
FiNCアプリ内の動画レシピにあります。
マイクロフロントエンドでマイクロサービスの独立性を妨げないだろうか
- 特定技術によると懸念の通りなので DOM is API
- Web Componentsなどの標準技術で固めることで影響を下げる
- windowsオブジェクトのせいで境界が1つなくなっている（グローバルになっている）
- グローバルに共有するような状態を避けるべき？
- 認証状態などグローバルなものは存在し得るし、それは良さそう
- サービス間で更新し合うようなものが生まれてしまうとそれは分けるべきではなかったということになる
GraphQLとマイクロフロントエンド
- GraphQLをマイクロサービスと使うときはアグリゲーションに使うケースが多い印象
- 独立させるためのマイクロフロントエンドとは相性良くないのではないだろうか
- BFFとマイクロフロントエンドは共存し得るか
- モノリシックを分割していった結果、BFFとして残ってアグリゲーションする部分となるのではないか
- マイクロフロントエンドはGraphQLを利用しなさそう
- マクロフロントエンドとBFFは相反するのではないか
- 目的が違う
- BFFはフロントに主眼をおいてバックエンドをまとめていく、ここでGraphQLを使う
- マイクロフロントエンドはバックエンドとフロントエンドの一貫性を求めている
- BFFはBFFにユースケースを含む、マイクロフロントエンドはリソース（バックエンド）直結なのでユースケースとも別
- BFFがモノリシック化しないように切り出していくとマイクロフロントエンド化していきそう
マイクロフロントエンド／マイクロサービスを扱う組織
- 類似サービスが生まれたときは競争させて良い方を残せばいい（富豪的な企業）
- 人リソースに合わせて選ぶアーキテクチャを理想ベースで選択している可能性
- 記述的な壁はなんとかなる
- Angular, React+Redux, React+Mobxの混在
- （Kaizenでは技術の統一はせずに発散を目指しているためいろいろ混ざっている）
- Angular, React+Redux, React+Mobxの混在
リポジトリ分割ができない理由
- 切り出したコンポーネントが独立して動くかどうか
- コピペだらけになると辛いし優先度低い
- リポジトリの分割を前提にしていない場合のコスト増が辛い
- デプロイフローも変わってしまう
- バージョン管理も
マイクロフロントエンド間でのAPIバージョニング
- マイクロサービスのバージョニングされている事が前提
- マイクロサービスに追従するはずでは
- ビルドの問題なのでは
- Web Components使っているならbundleしていないことはないんじゃないか
- bundleするときのバージョンで固定される
- bundleしていないものもバージョン指定してロードしている
- マイクロサービスの理想としてはbundleしない方がいいんじゃないか
- 理想だが現実として未知のバージョンとのリンクは非現実的ではないか
- Web Components使っているならbundleしていないことはないんじゃないか
- フロントエンドはロジックバグとUIバグの両方と戦っている
- DOMの破損だけではなく、CSSの破損も問題になり得る
- DOM, Event, Styleの正常性を担保しないといけない
FiNCスポンサートーク
- 人々を健康にする
- 行動変容を促す
- 継続させる
健康関心度モデルとサービスモデル
一般に関心度上位から攻める（ジムなど）
関心度モデル全層にアプローチする
多角的なサービスや機能を展開したい→マイクロサービスを採用
finc.comをMicro Frontends化します。CTO決済半分完了！