Upgrade to Pro — share decks privately, control downloads, hide ads and more …

自然発生した実装パターンに、マイクロフロントエンドと名がつきました / JSConf JP 2022

berlysia
November 26, 2022
8k

自然発生した実装パターンに、マイクロフロントエンドと名がつきました / JSConf JP 2022

berlysia

November 26, 2022
Tweet

Transcript

  1. 「マイクロフロントエンド」の確認 https://micro-frontends.org/ マイクロサービスで得たいこと - デプロイ単位の独立 - デプロイ頻度の向上 - コードベース・技術選択の独立 -

    捨てやすい、変えやすい - 自律した組織による意思決定 - 組織的にも疎結合 - サービス境界によるレジリエンス - 障害の範囲が狭められる
  2. 「マイクロフロントエンド」の確認 https://micro-frontends.org/ マイクロサービスで得たいこと - デプロイ単位の独立 - デプロイ頻度の向上 - コードベース・技術選択の独立 -

    捨てやすい、変えやすい - 自律した組織による意思決定 - 組織的にも疎結合 - サービス境界によるレジリエンス - 障害の範囲が狭められる えっ、フロントは?
  3. 「マイクロフロントエンド」の確認 モノリス フロント エンド モノリス フロント エンド マイクロ サービス マイクロ

    サービス マイクロ サービス フロント エンド マイクロ サービス マイクロ サービス マイクロ サービス マイクロ フロント エンド マイクロ サービス こうでもいいし こうでもいいし こうでもいいでしょ マイクロ フロント エンド マイクロ サービス マイクロ サービス
  4. 「マイクロフロントエンド」の確認 マイクロサービスで得たいこと(再掲 - デプロイ単位の独立 - デプロイ頻度の向上 - コードベース・技術選択の独立 - 捨てやすい、変えやすい

    - 自律した組織による意思決定 - 組織的にも疎結合 - サービス境界によるレジリエンス - 障害の範囲が狭められる マイクロ フロント エンド マイクロ サービス マイクロ フロント エンド マイクロ サービス マイクロ サービス フロント エンド マイクロ サービス マイクロ サービス マイクロ サービス
  5. オンライン学習サービス『N予備校』 - 双方向参加型の生授業 - コメントやアンケート、挙手の機能で授業に参加 - アーカイブ機能で見逃しても安心 - 完全オリジナル教材 -

    300以上のコース、多彩な教材 - 大学受験からプログラミング、クリエイター講座まで - フォーラム - 質問掲示板で疑問を解消 - 他の受講者の質問に答えたり、講師の方が答えることも
  6. 「マイクロフロントエンド」の確認(再掲 モノリス フロント エンド モノリス フロント エンド マイクロ サービス マイクロ

    サービス マイクロ サービス こうでもいいし こうでもいいし こうでもいいでしょ フロント エンド マイクロ サービス マイクロ サービス マイクロ サービス マイクロ フロント エンド マイクロ サービス マイクロ フロント エンド マイクロ サービス マイクロ サービス
  7. 教材周りのイメージ図 Webフロントエンド マイクロ サービス マイクロ サービス マイクロ サービス API Gateway

    教材 マイクロ 何か マイクロ サービス マイクロ サービス マイクロ サービス API Gateway 教材 マイクロ フロント エンド 教材 マイクロ サービス リリース当初 リリース2年後 Webフロントエンド 分離
  8. なぜこうなったか - 「マイクロフロントエンド」を知っていたとは考えにくい - マイクロフロントエンドという言葉が知られたのは 2016年末らしい - N予備校のリリースは 2016年4月 -

    日本で最初に盛り上がったのが 2018年? - ここだけを扱う専門チームがあったわけでもない - 当初はバックエンドの管理、じきにフロントエンドの持ち物となる - かつては機動力を要求される部分ではなかった - サービスの要求に対する技術的アプローチの結果ではないか - Web/iOS/Androidから同じ教材が使えて、同じ体験ができるようにしたかった - WebViewから使うことを前提にすると、 Webのときもiframeにすればやることは同じ - テキストとして自由度の高い Webページが書けるので、諸々良い感じに封じ込めたい
  9. この事例の特徴 2/4 簡素性 - iframeやWebViewとの通信部分はかなり問題になった - iframeの寸法管理も工夫が必要 - iframeの中身にあわせてiframeの寸法を調節したかったりする -

    ドメインの特殊性ゆえに特に問題になったが、 iframeじゃなかったらもっと大変だった テスト容易性 - E2Eテストはスマホもあるのでコストが高い。やってない - iframeのマイクロフロントエンドだから難しいということはなかった
  10. この事例の特徴 3/4 パフォーマンス - iframeを10個20個と開くと重いので、必要ないものはunloadしたい - ログイン前提なのでインデックスされない問題は気にならない 開発者体験 - マイクロフロントエンド単体で完結する限りは全く困難はない

    - ホストアプリケーションと結合しての動作確認やテストは困難を極める - Webだけならまだよいが、 iOS/Androidとの結合はかなり困難 - しかしWebViewで実装されていなかったら、それこそ困難であったろう
  11. WebView#createWebMessageChannel() - Androidのみ - Channel Messaging APIと同じような使い勝手 - WebView側のページはほぼ透過的に実装できる -

    Structured Cloneアルゴリズムには対応していないので JSON文字列にする - 双方向にやり取りできる
  12. WKUserContentController - iOS, WKWebViewのみ - WebViewからホストへの単方向のみ - 下記のような関数が生えて呼ぶとホスト側で受け取れる - ホスト側からWebViewへは

    evaluateJavaScript するしかない……? - そのための受け口を WebView側の実装に用意する必要がある - もっといい方法あったら教えてほしいです