merpay Frontend における BFF / bff-at-merpay-frontend

2018年6月7日に開催された UIT#3 The “Backends for Frontends” sharing https://uit.connpass.com/event/88434/ の「merpay Frontend における BFF」のセッション資料です。

Transcript

1. merpay Frontend
   における BFF
   UIT#3 The “Backends for Frontends” sharing
   Shogo Sensui (@1000ch)
   

   View Slide

2. Shogo Sensui
   (@1000ch)
   Software Engineer
   Merpay, Inc / Mercari, Inc
   

   View Slide

3. 「信用を創造して、なめらかな社会を創る」
   

   View Slide

4. メルペイ事業における Web
   ● 実現することが沢山あり、それ毎にプロジェクト化されている
   ○ 加盟店様向けに提供するダッシュボードとか …
   ○ お客様からの問い合わせに対応するための管理画面とか …
   ○ EC サイト（例）で「メルペイで決済する」ボタンを配置するための SDK とか…
   ● とにかく色々ある。それを Frontend チームで適時開発している
   

   View Slide

5. @1000ch 的なモチベーション
   ● 余程の事情が発生しない限り SSR + SPA を実現したい
   ○ SEO の有無に関わらずパフォーマンスを担保したい
   ○ アーキテクチャの難易度による初期コストはあれど、長期的に見れば誤差（要出典
   ● メルカリは React 製品で揃えているし、メルペイは違うものにしようかな
   ○ React はある程度触ったし、他のものを使いたい
   ○ React 以外の知見もメルカリ + メルペイに蓄積したい
   ● メルペイの Web 開発で使う技術はある程度揃えておきたい
   ○ 人員の再配置をしやすくしたい
   ○ メルペイ内で踏んだ轍を共有したい
   

   View Slide

6. メルペイ Web の技術スタック
   ● Vue
   ○ {} によるテンプレート構文
   ○ 双方向データバインディング
   ○ Virtual DOM による HTML の差分更新
   ● Nuxt
   ○ Next.js にインスパイアされたフレームワーク
   ○ フレームワーク制約の元で SSR や SPA を簡単に実現
   ○ 静的ファイルも出力可能
   ● CSS 周辺
   ○ PostCSS で @import をバンドルしたり autoprefixer したり　
   ○ CSS in JS は使わない
   ■ はつけておくが基本的には命名規則（ BEM）でケア<br/>

   View Slide

7. Web 周辺アーキテクチャの概観
   User Land Microservices Land on GCP
   Browser SSR Server API Server
   http
   Isomorphic App
   

   View Slide

8. そもそも BFF とは
   

   View Slide

9. “Single-purpose Edge
   Services for UIs and
   external parties”
   via Sam Newman - Backends For Frontends
   

   View Slide

10. The General-Purpose API Backend
    Microservices Land
    User Land
    image via: Sam Newman - Backends For Frontends
    

    View Slide

11. 広がる BFF の解釈
    ● BFF とは何なのか、会長が寄稿し
    てた
    ● そもそも「Frontends のための
    Backends だし…」感はある
    

    View Slide

12. >「これらの状況を鑑みて、フロントエンド側にクライアントごとの要求に応えるための
    サーバを配置してバックエンドのAPIサーバとの橋渡し役とするアーキテクチャが開発さ
    れるようになりました。BFFによってHTMLを構築したり、リクエストの数を少なくしたりで
    きるなどの利点があるからです。」って会長が言ってた
    

    View Slide

13. The General-Purpose API Backend
    Microservices Land
    User Land
    HTML を生成させると
    色々都合が良さそう
    image via: Sam Newman - Backends For Frontends
    

    View Slide

14. メルペイにおける Backends For Frontends
    User Land Microservices Land on GCP
    Browser SSR Server API Server
    http
    Isomorphic App
    

    View Slide

15. メルペイにおける Backends For Frontends
    User Land Microservices Land on GCP
    SSR Server API Server
    広義(?)の BFF
    本来(?)の BFF だけど
    Backends for BFF 状態
    

    View Slide

16. 今日だけ BFF と Backends for BFF を区別します
    User Land Microservices Land on GCP
    SSR Server API Server
    BFF
    Backends for BFF
    

    View Slide

17. 違う Backends For Frontends 案（ボツ案）
    User Land Microservices Land on GCP
    SSR Server
    http
    Single Purpose ではな
    くなってしまっている
    http
    http
    Browser
    

    View Slide

18. Node.js が API サーバーを兼ねてはまずい？
    ● 責務をキレイにしたかっただけ
    ○ Node.js: Isomorphic App を動かすサーバー
    ○ Golang: クライアントサイドの通信先となる API サーバー
    ○ Frontend と Backend の関心を分離できる
    ● 仮に Node.js が API サーバーを兼ねようとすると
    ○ マイクロサービスがひとつ減る
    ○ クライアントサイドの設計に応じて Frontend が API サーバーを修正できる
    ○ SSR 時の Node.js → API (Backend) へのエンドポイントをどう設計するの問題
    ○ SSR 時の処理だけでなく API リクエストも受け付けることによる負荷への懸念
    

    View Slide

19. BFF もとい Backend for BFF がやっていること
    ● 基本は API Gateway として動作させる
    ○ つまり HTTP リクエストを（gRPC に変換して）を後ろに横流しているだけ
    ○ 将来的にはアグリゲーションさせるかもしれない
    ○ Isomorphic App がどのリソースへアクセスし何をするかを知っておく
    ● axios が http/2 対応するのを心待ちにする
    ○ Backend for BFF への HTTP リクエストの数は一旦忘れる
    ○ Backend for BFF から後ろは gRPC (http/2 上) なのできっと大丈夫
    

    View Slide

20. おしまい
    

    View Slide