Microservices Meetup vol.9 (FiNC App & Frontend) 参加レポート

• connpassページ

はじめに

今回クライアントサイド視点から見たマイクロサービスに関するトークということで、スマホアプリ開発を担当している自分にとっても興味がある内容でしたので参加してきました。
スマホアプリ開発に関連するトークを中心に感じたことを記載していきます。

トーク

ウェルカムトーク「マイクロサービスとクライアント: 理想と現実の狭間で」

@qsonaさん
資料

• マイクロサービスの良さ

  • 技術異質性
  • 回復性
  • デプロイの独立
  • 小さく自立・独立した組織

• エンドユーザーはマイクロサービスを見たいわけではなく、統合された体験を望んでいる

  • 結合レイヤーを理解して、適切に対応する必要がある
    • コミュニケーション・責任の所在の明確化・優先順位付け

• フロントエンドエンジニアはエンドユーザーを最も強く意識する

  • 紹介された記事
    • 社内の“ハブ”として機能するフロントエンドエンジニアリング　by FOLIO　倉見さんの記事

• Backends For Frontends(BFF)

• Micro Frontends

クライアントサイドから考えるマイクロサービス

@neonankitiさん
資料

• サーバサイドがマイクロサービス化されていっても、クライアントサイドの実装コストはほぼ変わらない
  • ただし、1画面でコールするAPI数は増える
• 運用面の問題はある
  • 各サービス間のリソース表現が異なる
  • スマホアプリ側では同じリソースは同じモデルとして扱いたい
    • 腐敗防止層の設置
    • シェアと合意形成のため、同一職能(iOSエンジニア・Androidエンジニア)でのコミュニケーション強化
  • iOS/Androidエンジニア間での設計齟齬・ドメインモデル差異・会議に両エンジニアが必須
    • iOS/Androidエンジニア間のコミュニケーション橋渡しのためClient Fusionを導入
    • 各テックリードエンジニアが戦略を立て、アプリエンジニア全体定例でシェアをする
    • 即効性は無いが、徐々に効果が出てきている
• マイクロアプリ化
  • クライアントアプリ内の分割されたマイクロサービス
    • ドメイン毎のアプリインストール
    • 自律性
    • AndroidアプリはInstant Appsを利用すれば実現可能
  • マルチモジュール
    • マルチモジュールのすゝめ by @kgmyshinさん
  • マイクロアプリは近い未来にくる
    • AndroidアプリはマルチモジュールやInstant Appsがあるが、iOSはまだ難しいのでは？

マイクロサービスとクライアントとコンテキスト境界

@takasek さん
資料

• クライアント・サーバ間のコンテキスト境界をどこに置くか

  • BFFの場合
    • 整合性についての心配事をドメインから排除
    • プラットフォーム間での重複実装排除
    • 分散コンピューティングの原則への挑戦
  • Repository
    • 整合性についての心配事をドメインから排除
    • データの永続化・隠蔽を担うRepositoryがビジネスロジックも保有
    • プラットフォーム間での重複実装
  • UseCase
    • ビジネスロジックを実装する層でもあるのでしっくりくる
    • プラットフォーム間での重複実装
  • ViewModel
    • 責務の肥大化
  • View
    • Viewはマイクロサービスではない。エンドユーザーは統合された体験を望んでいる。

• クライアントが担保すべき整合性

  • Model と View 間の整合性
  • Model と Model の整合性
    • クライアントが保持しているサービスの状態はスナップショットでしかない
    • クライアントはマイクロサービス間の関係性の知識を持たざるを得ない

• 「ビジネスロジック」の定義はアプリ・サービスによって異なる

実践、BFF ~ BFFはFiNCのアプリで何を解決したのか ~

@izmeal2000 さん
資料

• BFF

  • マイクロサービスの提供する複数API群とクライアントの仲介レイヤー
  • 解決できる課題
    • 通信パフォーマンス
    • 集約ロジックの共有
    • 些細な挙動変更であればBFFの修正で対応が可能
  • 通信を1本に集約すると別の問題が起こるので、適度な粒度で集約する
    • 遅いAPIに引きづられる
    • 個別Retryができない

• BFFの開発はクライアントエンジニアが開発すべき

  • コミュニケーションミスが発生しがち
  • BFFはUIチームによって開発されるものである by　SamNewman
  • Fincは Kotlin + Spring Webflox + protobuf で開発中

まとめ

マイクロサービス,BFF,DDDというキーワードが(当然ですが)何度も出てきました。
正直な所、上記のキーワードに対してフワッとした理解しかしていない状況で今回の勉強会に参加させて頂いたので、トークの内容を理解するのに苦労しました。

ビジネスロジックの共有という点ではBFFを利用してサーバーサイドで集約するという話がある一方で、懇親会ではReact NativeやKotlin Native, Flutterといった所謂クロスプラットフォーム開発ツールを用いてクライアント側でも集約できないかという議論がありました。
確かにサーバーサイドで集約しちゃった方が良いものもありますが、全てがそうではありません。
その場合にはiOSはSwift,AndroidはKotlinで同じビジネスロジックを重複実装しなければなりません。
クロスプラットフォーム開発ツールを用いてビジネスロジック部分は集約しつつ、UIやプラットフォームに依存するような機能は個別実装できるようになれば、iOS/Androidエンジニア間での認識齟齬も減りコミュニケーションコストの削減にも繋がるなと感じました。
但し、現状ではまだまだこれらのツールには課題があり、アプリの規模や導入タイミングによってはデメリットが多くなりそうです。
しかしながら、Kotlin NativeはBeta版、FlutterはRC版と今後の開発にも期待ができそうなので、ウォッチしていこうと思います。