UIT#3 The “Backends for Frontends” sharing

に行ってきたので、そのときのレポート

「マイクロサービスの思想から捉える、Backends for Frontendsとその類似パターン」 qsona (株式会社FiNC)

資料

以下、講演を聴きながらのメモ

「BFFとは」「その位置付けと目的」

backend for frontendという言葉は少し混乱がある。

server for frontendという言葉のほうが実態に近いように思う。

複数のAPIを合成したりする位置付け

UI側でのABテストなどをする

BFFとマイクロサービスの関係性

マイクロサービスとは、協調して動作する、小規模な自律型のサービス

FINCアプリの場合は、各プロダクトが様々な機能を内包している。

機能の1個1個、それが単体でも事業になりそうなものが

FINCアプリの中にある。

それらを別々のマイクロサービスとして扱っている。

様々なクライアントと様々なサーバーがある。

それらを直接組み合わせると、

APIのコール数が増えるなどの問題がある。

その解決策として、中間に1つサーバーを挟む。

それを API Gateway として扱っている。

このAPI Gateway には独自のロジックは持たせたくない。

ロジックを持つと、マイクロサービスの旨味が減ってしまう。

注意点

バックエンドロジックをAPI Gateway にもりもりしてしまうと

辛くなる。

宣伝

Microservices architectureよろず本というのを書いたので、読んでね！

類似パターン

クライアントとBFF層のやりとりはgRPCにして

BFF層をkotlinで書く。

iOS と Android は基本的に同じ構成をしている。

画面遷移など。

デザインによる違いなどの吸収はクライアント側で行う。

gRPCにした理由は

RPCにしたかったから。

レストフルは避けたい。

クライアントの要求に答える形なので、RPCとしたかった。

Kotlinの理由

既にいる Kotlin エンジニアのコストが減る。

並列処理として go や node.js を使おうかという考えもあったが、

コルーチンでギリギリ行けそうなので Kotlin

「FOLIOのBFFと秩序の話」 Quramy (株式会社FOLIO)

以下、講演を聴きながらのメモ

「FOLIOのBFFと秩序の話」 Quramy (株式会社FOLIO)

今日話すこと

FOLIO の BFF の自慢話

こんな失敗したのでみんなしないでねという話。

イントロ：サービス紹介、システム構成

MobileAPP と Web で大きく BFF を分けている。

モバイルアプリの iOS とAndroid へ提供している API は同じもので

デザインによる違いはクライアントで吸収させている。

BFF のお仕事

下流サービスの集約

Web の BFF は SSR(サーバサイドレンダリング)も行なっている

Aパート：良い話（うまくいった自慢話）

まずアーキテクチャはどんなのを採用しているか？

クリーンアーキテクチャ風

なぜこんな風にしているか？

BFF はクライアントやマイクロサービスに挟まれているので

クリーンアーキテクチャが親和性が高いと思ったから。

主な目的は型付け。

Json でやりとりをしていて、 Node.js を採用しているので、

型をつけたかった。

リクエストやレスポンス整形で誤っていればコンパイルエラーになるようにしている。

BFF の思想を決めておく

やるべきこと、やらないことを決めておく。

日付の計算やパースフォーマット、数値項目の加算原産など

チームでこれらのことに合意をとって進めて行くと良い。

Bパート：辛かった話（失敗した話）

Web の BFF と Mobile の BFF は作られた時期が全然違う。

Webのほうが古くて、それでつらかった部分を考慮して Mobile が作られている。

悲劇の紹介

ユーザーがみるダッシュボード的な画面。

ログインした次の画面、マイページ的な。

これが辛い。

薄いコントローラと巨大なロジック層によって

巨大な Json を返す。

React を採用しているので、クライアントで Json を処理する。

辛い部分として、

巨大なロジック層の部分が 1800 行とかある。

また、型も Any にしている。

型がついてないし、巨大なので触りたくない状態。

だが、旧来のMVCの形をしているので、ある意味わかりやすい部分はある。

直近の対処

改修をする際には、なるべく型付けを少しづつしていってリファクタリングをしている。

もう少し先の対応としては、

React コンポーネントが必要な Json を取りに行くという

画面側が必要な部分だけ取りに行く。next.jsのような思想を目指している。

おさらい

秩序をもたらすためには、

レイヤを意識しよう
ユースケースを意識しよう
スキーマ + 型を使おう

「merpay Frontend における BFF」 @1000ch (株式会社メルペイ)

資料

https://docs.google.com/presentation/d/1RY2qCIypDBju2LfVhBfBnBaaVN_SFM_KAz7-WVucl90/edit#slide=id.p

以下、講演を聴きながらのレポート

BFF のことを調べていたら

「使う側にとって、良い設計になっているバックエンド」

という文献に当たった。

最初は、API をまとめるための API サーバーという認識だったが、

複数の API サーバーにリクエストして、htmlを生成するサーバーも BFF と呼ぶ。

と、古川さん（Node.js会長の）が言っていた。

backend for frontendsという言葉なので、捉え方によってはなんとでもなりそう。

広義の意味では SSR Server を BFF と行ったり、

API をまとめる APIサーバーを backend for BFF という捉え方もできる。

node.js が API をまとめるようにしたくなかった。

isomorphoic app を動かすようにしたかった。

フロントエンドの人が js を触っているので、

その人たちもメンテナンスができる。

backend for bff がやっていること

API Gatewayとして動作させている。

httpリクエストを gRPC に変化して横流しする。

将来的にはアグリゲーションさせるかもしれない。

「なぜBFFを導入しなかったのか」 Kento Moriwaki (Wantedly, inc)

資料

Bffを導入しなかった理由（僕らにはまだ早かった）

以下、講演を聴きながらのメモ

システム構成

railsの一枚岩だけど Micro Service 化を進めている。

バックエンドとフロントエンドの責務を分けて行きたいと思って、

BFF の登場だ！ということを考えた。

課題

グローバルヘッダーやフッターは全ページ共通

ただ、SSR 化したかったのは、ヘッダーやフッターを除いて中のコンテンツを SSR したかった。

共通パーツ問題を解決するために考えたこと

reactバージョンを作る？
rails jqueryで2重管理になってしまう
全部react実装に統一する？
Angularもいれていたので、Angular と React を2重管理させるのはカオスになりそうだった。

課題:インフラの問題

どうやってデプロイするか？

切り替わりの間で何か障害が起こったときのインパクトがでかすぎる。

また、画面を少しづつ移行させたいという要望もあった。

これらの課題を解決するに至らず、BFF は挫折した。

今後は

これらの要件を満たしつつ、最小限の工数で。

BFF は目的じゃなくて手段の一つ。

もともと作っていた Restful API でやってきたこと

model を json に変換するところを共通化していた。

複雑な処理もあるが、小さい Service 単位に切り出していた。

これらのことのように、Controller を薄くしておいたおかげで

さまざまな部分を共通化できた。

今後もし BFF に対応したかったら、

対応する API を叩くように書き換えるだけ
BFF で直接 Render することも可能。

まとめ

SSR したいだけなら、BFF は必須じゃない

ただ、BFF のメリットはすごくあるので

1つ1つ疎結合にしていって、一歩ずつやっていこうと思う。

「LINEとBFFの話」 Jun (LINE株式会社)

資料

https://speakerdeck.com/noraesae/line-and-bff?slide=1

以下講演を聴きながらのメモ

LINEは、

サーバの人が多い
サーバは Java, Perl
サーバーサイドテンプレート
SPA でもindex.htmlはサーバーに置いてある

BFF というものは

フロントエンドとか技術だけの話だけではないと思う。

BFF の導入は慣れているプロセスを破壊するものなのか？

破壊は改善です！というのも、エンジニア以外から「本当に？」と思われてしまう。

BFF というのは、組織と責任が伴う。

BFF がなかったら、テンプレートがサーバーにあるため、責任が不明確。

例えば、画面の問題があって、テンプレートはサーバーにあるため

サーバーのエンジニアが見る

からの、「これはテンプレートの問題ですね」

となって、フロントエンドエンジニアが対応する

これは非効率

また、「これくらいのテンプレートならサーバーサイドエンジニアでも直せるや」

と思って直すと、フロントエンドエンジニアの人の知らないところで変更が入ってしまってつらい。

BFF があると

問題の切り分けが効率がよい。

サーバーサイドエンジニアはデータを触るだけ

フロントエンドエンジニアの人も、渡ってきたデータを触るのに集中できる。

何か BFF で問題が発生した場合は

インフラの人と責任分担して解決しよう。

SEO/OGP/i18n

のことは、最初から考慮して設計しよう

あとからの対応はほぼ無理になる。

performanceに関わること

BFF を導入しても遅くない。

むしろ早い。

node.js の速さもある。

内部ネットワークでの data fetch をすると rtt 1桁くらいになる。

「BFF しましょうとなったときに気をつけたいこと」

結果的にいいもの作って証明しないといけない。

開発環境を慎重に選びましょう

責任をちゃんと話し合いましょう

計測できるようにしましょう。

　→ 数字がないと、何がよくなったのか証明できない。

結論

BFF はいいものだが、それだけじゃ進まないときもある

他の組織と話合おう

責任を分け合って、一部だけがつらくならないようにしよう。

結果的に良いものを作って、みんな幸せになろう。

「BFFアンチパターン」 @yosuke_furukawa

資料

バックエンドとフロントエンドを分けること自体がアンチパターンだという文献もある

そこで書かれていることが、

「どちらにも詳しいという人がいなくなってしまうし、責任の所在が不明確になったりもする。」

古川さんが BFF アンチパターンを書いていたときに

だんだん組織アンチパターンになってしまった。

BFF はフロントエンドとバックエンドの架け橋。

アンチパターンその1:スパースコミュニケーションのアンチパターン

BFF はアーキテクチャを疎結合にするが、

コミュニケーションまで疎結合になってしまうパターン。

n+1 queryのパターン

マイクロサービスだからといって

API を簡素にしていい訳ではない。

これらのことは、コミュニケーションをとらなかったから起こったこと。

アーキテクチャは疎であったとしても

対等な存在であり、コミュニケーションは密に行おう。

アンチパターンその2:インフラレスポンシビリティ

フロントのために BFF を導入したのに

何か BFF で問題があったとき、その責任をバックエンドに押し付けてしまうという問題

BFF は全員でみるべきものであるので、みんな当事者意識をもつようにしよう。

アンチパターンその3:ビックバンジョイント

フロントとバックエンドを別々で開発しており、

お互いに開発が完了した段階で結合テストをしましょうという段階で

確実に想定外のレスポンスが存在する。

なので、最後の最後で結合してあとは結合テストということができない。

なので、結合テストの部分はスケジュールを長く持たせないといけない。

古川さんたちがやっていることとして、

開発中にモックで作っているものを、

お互いの開発が部分的に終わったら、終わった部分から少しずつ本物にしていくということ。