はじめに
こんにちは、エンジニアの最上です。Microservices Meetup vol.5 (API Gateway & BFF)がFiNCさんで開催されまして、それに参加してきましたので、簡単ではありますがそのレポートになります！
BFFとは
Backend for Frontendの略。ボク個人の解釈としては、クライアントBFFAPIといった立ち位置で、クライアント（Web・アプリ）ごとに最適化した形式に変換してくれるものです。
発表内容
APIのことはすべてシーマンが教えてくれた。
Oracleの早川さんの発表でした。スライドはこちら。
開発者（わたし）と、様々な人との距離感があり、それぞれに目標やコミュニケーション方法、サービスのリリース時期などの観点で整理し、APIに求められることをマイクロサービスで作り、求められることをBFFとして切り出して最適化させていく。
step by step BFF
日本Node.jsユーザーグループ会長の古川さんの発表。スライドはこちら。
BFFのユースケースとして - APIコールをBFFでまとめてフロントに最適化した形で返却する - セッション管理 - サーバーサイドレンダリング - ファイルアップロード - リアルタイム処理 がある。
実例として - Twitterの、Scalaでマイクロサービス作って、BFFをNode.jsで作成した話 - Netflixの、デバイスが異常に多いのでBFFでそれぞれに最適化させた話 があげられた。
BFFを導入するときは - フロント、バックを分業したいとき - レガシーなシステムを少しずつリアーキテクトしたいとき
BFFを導入しないときは - フルスタックエンジニアが多い - モノリシックで速度を優先したいとき - SEOいらないとき があげられた。
Webサービスの初期開発とマイクロサービス・BFF
アカツキの高松さんのお話。スライドはこちら。
できるだけAPIを単純化し、細かい粒度で作ることによって、設計・実装・テストが簡単になり、バグもほとんど起きなかった。その中で、レスポンスをできるだけ低下させずに、フロントエンドに最適化させるためにBFFを導入していった。
BFFの実装は難しくないけど、複雑で面倒なことが多いため、チームにはなかなか受け入れてもらうのに時間がかかった。
ウェルネスタイム
恒例のウェルネスタイム！弊社でもいろいろ取り組んでいますが、職業柄座りっぱなしであるため、こういった運動は大切ですね！
Railsで作るBFFの功罪
リクルートライフスタイルの@shotat_jpさんのお話。内容はこちら。Railsの話が多く、正直細かい部分は理解できないことが多かったです。
10年運用したシステムが密結合＆レガシーで、非常につらい。そこで、バックエンドとBFFを切り離して、モノリシックじゃなくした。優先度とゴールを明確に決めて、その中で選択を繰り返していった。
懇親会
手作りの料理がたくさんでてきて、とってもおいしかったです。また、FiNCさんのエンジニアの方とも交流でき、非常に実入りの多い懇親会でした。
感想
現状、僕は僕含めて開発者2人のチームですべてを開発しています（アーキ設計からフロント、バックエンドの開発まで）。コミュニケーションも密に取れていて、BFFを入れなければならない！という感じでは正直ありません。しかし、APIをできるだけシンプルに作成し、クライアントごとにBFFを作成しておくことによって、APIを使いまわすことができ、より効率よく開発が進められるのではないかと思いました。
今すすめている案件では、Node.jsを使ってサーバーサイドを作り、WebフロントはRiot.jsで作っていますが、サーバーサイドがもはやBFFのような形になってしまっています。現在のサーバーサイドを、APIというかたちでマイクロサービス化していくことで、今後クライアントが増えた際にも柔軟に対応できるのではないかという結論に先輩と至りました。
今回の勉強会で、クライアントサーバーという固定概念がくずれさり、間にBFFという柔軟な要素が入ってくることも大いに有り得るということがわかったことが最も大きな収穫でした。
おわり。
