読者です 読者をやめる 読者になる 読者になる

Microservice Meetup #5 参加ブログ1(step by step BFF)

Inside FrontEndに引き続き、ブログ書く枠で参加させて頂きました。
今回で5回目となるMicroservice meetupですが、中々都合がつかず、
個人としては今回が初めての参加になります。

microservices-meetup.connpass.com

発表項目

APIのことはすべてシーマンが教えてくれた。」 by @charlier_shoe さん

www.slideshare.net


「step by step BFF」 by @yosuke_furukawa さん
speakerdeck.com


Webサービスの初期開発とマイクロサービス・BFF」 by @shimpeiws さん
speakerdeck.com


Railsで作るBFFの功罪」 by @shotat_jp さん
engineer.recruit-lifestyle.co.jp

をベースにした話

step by step BFF

個人的には一番今構成について議論している環境に近く、参考になるセッションでした。
まずはこちらのセッションについてまとめます。

日本Node.jsユーザグループ代表,RecruitTechのFurukawaさんのお話

1 BFFとは

  • フロントエンドとバックエンドを明確に分ける、マイクロサービスを意識するためのもの
  • 皆さんがよく引用する、SamNewmanの記事も紹介

Sam Newman - Backends For Frontends

  • ドメインに特化したサービスとリッチなクライアントを繋ぐ調停役
    • 画面を作るための補佐
    • API Aggregation

2 BFFが担う役割

このパートが聞けたのよかった。

1 API Aggregation

Aggregation : 集約する、集合体、集合させる

ここは特に異論ないところだと思います。
非同期で複数のMicroserviceをCallし、フロントエンドが必要な形に整えて返す
という役割です。

2 Session Management

API Gatewayの観点からすれば、これも自然な役割だと思います。
セッションを元にtokenを取得して、tokenを利用して各APIにアクセスする部分をBFFでやります。

3 (Server Side) Rendering

これは、SPA(Single Page Application)が関連してきますね。
これをはっきりBFFの役割に入れてるのは面白かったです。

4 File Upload

これまた面白い話。
ファイルアップロードする機能そのものは、BFFに実装したという話。
これは同じような悩みをした経験が・・・。

・ファイルをアップロードする行為そのものはRestと相性が悪い
・BFFでAWSのS3みたいな所にファイルアップロードは済ませて、
そのfilepathをrequestに入れてファイルを管理するrestful apiにリクエストする
みたいなことをおっしゃっていたと思います。

5 WebSocket / LongPolling / SSE(Server Sent Events)

WebSocket / Long Polling / SSEも、BFF経由で行う。
Message QueとのやりとりもBFFが直接行う。

Cache

具体例の紹介があったわけではないですが、スライドには
CacheもBFFでやるとbackend-friendlyという話がありました。
色々な場所でキャッシュし始めるとヤバいので、同意

3 BFFが生まれた背景

Previous BFF pattern

  • 1990 ~ : 3tier Client-Server System
  • 1990 - 2000 : Monolitic Architecture
  • 2010 : Single Page Application
  • 2013 - ? : Single Page Application with Microservices
  • クライアント側にロジックがよりがち
  • フロントエンドはUIに集中したい
  • ということを考えるとBFFが必要

という流れだった。

  • BFFをNode.jsにするとFrontEnd(SPA)と作業を共通化できる

という話があったので、こんな疑問を思いました。


で、ここら辺で発言したことをパネルディスカッションの時に(恐らく)拾って頂いて、
確認したところ、やっぱりBFFはフロントエンド側で管理しているらしい。

4 BFFの利用事例(Twitter,Netflix,RecruitTech)

1 Twitter

何かと話題になったこの件笑


Mobile TwitterがNodeでアクセスを受け始めた。ということです。

29スライド目にあるような構成だと、まさにSPA+BFF(Node,Express,React)で構成されている感じみたいです。
Mobile Twitterというのはこっちのことですね。

https://mobile.twitter.com/home

2 Netflix

Microserviceの話になると大抵Netflixの話が上がります。ブログを読むと僕らが今直面してる課題が、
数年前のブログのっていたりして辛くなることがありうます笑

3 RecruitTech
  • BFFをNode.jsで構築
  • 上にあるような使い方をしている

例としてブッキングテーブルというサービスの構成が紹介されていました。
ブッキングテーブルではネイティブアプリとWEBでBFFを分けているみたいです。

bookingtable.jp


あとは、raicoというサービスも紹介されていました。(見つけられなかった

5 どのようなタイミングでBFFを導入する/しないのか

するとき
  • フロントエンドとバックエンドで開発者を分業して、疎結合にしたいとき
  • レガシーなシステムがすでに存在しており、段階的にリアーキテクトしたい
  • ユースケース上必要になる場合
しないとき
  • フルスタックエンジニアが多いとき
  • Monolithcに開発して最速でサービス出したい時
  • ユースケース上必要ない場合

6 どのように段階的にBFFを導入するか(Step by step BFF)

  • BFFをProxyとして構築する
  • 最初はレンダリングするところだけ
  • だんだんと内部の処理を置き換えていく

所感

  • まず、しっかりと実例が聞けたとき点において大変参考になった
  • Backend側の話はそんなに無かったが、綺麗なRestfulにする為にBFFが色々やってる(ファイルアップロードとか、websocketとか)というのもありそう。(フロントの為だけじゃなくて
  • そこが調停するっていう表現なのかな
  • エラーメッセージのハンドリングとか、聞けばよかった
  • このセッションに限ったことではないけど、BFFがAPI Gatwayを包含している感じだった