「UIT#3 The “Backends for Frontends” sharing」に参加してきました

• 2018/6/7
• https://uit.connpass.com/event/88434/

マイクロサービスの思想から捉える、Backends for Frontendsとその類似パターン

• qsona (株式会社FiNC)
• MicroservicesMeetup主催
• https://speakerdeck.com/qsona/backends-for-frontends-and-its-similar-pattern-from-the-microservices-perspective

BFFとは

• サーバ
• Servers for Frontendのが実態に近い
• Frontendにもサーバがほしいと
• Frontend/Backend
• Client/Server

なぜBFF

• APIを合成する
• microservices

マイクロサービス

• 自律的なサービス

• 独立したリリースサイクル

• クライアントとサービス

  • モノリシック
    • n:1
  • マイクロサービス
    • n:m
• 問題点
  • 様々なホストを知ってないといけなくなる
  • そこでAPIGateway
• でもAPIGatewayにはロジック書きたくない
  • APIGatewayはバックエンドエンジニアの領域
  • APIGatewayいじったときにバックエンドいじらないといけないとかは嫌だ
• そこでBFF
  • クライアント単位でBFFを立てる
  • BFFはフロントエンドが管理する

BFFの類似パターン

• ios/android両方に対するBFF作る
  • grpcでやりとり
  • クライアントのコールに対して返したいからRESTじゃない
• バックエンドRails
• BFFはkotlinで
  • 並列処理したい
  • android/iosからのコンテキストスイッチ低い

マイクロフロントエンド

• UIもビジネス
• バックエンドもフロントエンドもいる縦に切ったチーム
• 実現のために
  • iframe?
  • WebComponents!
• 課題
  • UIUXの一貫性担保
  • 独立してやるのと一貫性はトレードオフ

FOLIOのBFFと秩序の話

• Quramy (株式会社FOLIO)
• https://speakerdeck.com/quramy/bffs-cosmos-in-folio-sec-at-uit

FOLIOのBFF

構成

• バックエンド
  • マイクロサービス
• BFF
  • PC用/モバイル用
• フロントエンド
  • PC/モバイル

BFFのやってること

• APIの集約
• SSR
• 認証/セッション管理
  • kong

BFFの良い話

• BFFは外界に挟まれてる
  • クリーンアーキテクチャと親和性高い
• フレームワークの依存の排除と型付け
• 型
  • swagger-to-flowtype
  • thrift2flow
• 責務
  • BFFでできることはやる
  • 日付の計算
  • 数値の計算符号付け単位

BFFの辛い話

ダッシュボードでのSSR

• ログイン直後の画面
• コードがでかいし型がない
  • BFFで通信を束ねてでかいJSON返す
  • koaもJSONも型なし
• 改善
  • 型付け
  • テスト
  • CIで落ちるようにする
  • 画面の側がリソースを取りに行く
    • 巨大なのをもらうわけではなく

まとめ

• レイヤを分けよう
• ユースケースを考えよう
• スキーマと型を使っていこう
• アグリゲーション対象が増えてからだと大変

merpay Frontend における BFF

• @1000ch (株式会社メルペイ)
• https://docs.google.com/presentation/d/1RY2qCIypDBju2LfVhBfBnBaaVN_SFM_KAz7-WVucl90/

メルペイのアーキテクチャ

• Browser(Vue+Nuxt) - SSR(Node) - API(go)
• SSRするサーバから見ても使いやすいように
  • goのAPIがBackend for BFF的な

BFF

• BFFの出典
  • https://samnewman.io/patterns/architectural/bff/
• APIをまとめるもの
  • もうちょっと広い
  • SSR
  • http://www.atmarkit.co.jp/ait/articles/1803/12/news012.html

NodeがAPIサーバを兼ねるかどうか

• SSRするNodeがAPIへのエンドポイントをどう設計するのか

なぜBFFを導入しなかったのか

• Kento Moriwaki (Wantedly, inc)
• フロントエンドチーム5人
• 最近RNも導入
• https://speakerdeck.com/kentomoriwaki/bffwodao-ru-sinakatutali-you

会社ページリニューアル

• アーキテクチャ
  • React
  • SSR
  • TS
  • モノリシック -> マイクロサービス

課題

• 共通パーツをどうするか
• SSRしたいのは一部のページだけ
• 既存のページはいじりたくない

もともとやりたかったこと

• SSR
  • ユーザ体験向上とSEO
• Aggregate data
  • 既存のRESTfulAPIを使いたかった

どうしたか

• BFFやめた
• Hypernova入れた
  • AirbnbのSSRするNodeのサーバ
  • データを投げるとHTMLにしてくれる

まとめ

• SSRしたいだけならBFF必須じゃない
• 疎結合を意識して少しずつ

LINEとBFFの話

• Jun (LINE株式会社)
• https://speakerdeck.com/noraesae/line-and-bff

LINEのフロントエンド

• 300リポジトリ
• 100人
• ほとんどWeb
• Vue/React

LINEのBFF

• なれてるプロセスを破壊しないか
  • この破壊は改善だと広めないといけない
• Vue+Nuxt/React+Next

BFFがないと

• テンプレートがサーバにあるため責任が不明確
  • 問い合わせがサーバ側に
  • サーバ側が修正し始めるとつらくなる
• フロントエンドの修正だけでもサーバ配信が必要

BFFあると

• 責務が明確
  • サーバ：データ処理
  • フロントエンド：その他

課題

• サーバ側がNode経験ない
  • Node,npm,PM2
  • http://pm2.keymetrics.io/

パフォーマンス

• 物理的速さ
  • Node
  • DataFetch
    • 内部ネットワークだとRTT1桁くらい
• 心理的速さ
  • FirstMeaningfulPaint

BFFを入れる

• いいものを作らないといけない
• 計測すること
• 責任を明確にすること

まとめ

• BFFはいいけどそれだけじゃ進まないことも
• 責任が偏らないように

BFFアンチパターン

• @yosuke_furukawa
• https://speakerdeck.com/yosuke_furukawa/bff-antipattern

2年間やってみて陥ったアンチパターン

• BFFはフロントエンドとバックエンドの架け橋
  • 関わる人が多い

スパースコミュニケーション

• BFFはアーキテクチャどうしが疎になる
  • コミュニケーションまで疎になってしまう
• select分そのまま見える
  • joinの結果がそのまま見える
• n+1クエリ
  • リクエスト何度もなげる
• マイクロサービスだからといってAPIを簡素にしていい訳じゃない
  • バックエンド
    • BFFあると言ってもビジネスロジックはサーバ
  • フロントエンド
    • どういうAPIがほしいか言わないと
  • 関係は対等だからコミュニケーションとらないと
• リクルートでは
  • Agreedを使ってる
  • モックサーバ
  • https://github.com/recruit-tech/agreed

インフラレスポンシビリティ

• BFF誰が面倒見るの
  • 全員

ビッグバンジョイント

• 最後の最後にフロントバック結合すると死ぬ
• APIのリクエスト/レスポンスは想定通りじゃない
• 確実に想定外の問題は起きる
  • リクエストの型
  • statusコード
• リクルートでは
  • Agreed+proxy
  • できたAPIから本物をつなぐ
  • フロントが先行して作っていく必要ある

まとめ

• アーキテクチャは疎にしてもコミュニケーションは疎にしてはいけない
• インフラを見るのはバックエンドだけではない全員で見る必要がある
• 最後の最後に結合ではなく徐々に結合
• DevOpsのようにフロントエンドバックエンド