サイト内検索
Translation here

2017/03/30(木)【後編】Microservices Meetup vol.5(API Gateway & BFF) #microserv

Finc.PNG

前編はこちら。
【前編】Microservices Meetup vol.5(API Gateway & BFF) #microserv

Railsで作るBFFの功罪(@shotat_jpさん)

登壇者紹介

SIerさん
Case Studyのメインに

エンジニア不在でできたシステム

これを改修・リプレイスする。
  • 密結合→疎結合に
  • マイクロサービス化・BFF導入→導入の壁

サービスの分割は諦めた

古いアプリケーションを徐々に疎結合に切り出して最終的に廃止していく方針に

基本設計・方針

  • REST原理主義にならない
  • API呼び出し回数は押さえる
  • 全ての情報を詰め込めばよいというものでもない

社内の現状と切り分け

Java,Rubyベース。社内にエンジニアとノウハウが多かったため。

BFFをRailsにする懸念

Ruby自体が遅い
Golangがベストだが……

発表が早すぎて記事にするのを諦めました

ここだけ後で書きます、すみません……

ディスカッション

  • @charlier_shoeさん
  • @yosuke_furukawaさん
  • @shimpeiwsさん

API GatewayとBFFの違い、責任の持ち方について

  • BFF(含む)API Gateway
  • 流動制御とか
  • APIまとめたい、それぐらい

(Oracle)API Gatewayが担保してくれる範囲は?

標準化レイヤーは設定で出来る(認証とか監視?)
ファイルアップロード・WebSocketはどうだろう……?

BFFがない場合はバックエンドで持っているが、どこまでBFFに寄せられるのか?

→バックエンド(マイクロサービス)のロジックはセキュアなものを扱う事が多いが……?
フロント側からコンシューマドリブン駆動でやってるので、サーバー側は指定の値を返す。
どっちが主導権を持っているか、という問題かなと。

POST関連についてはAPI側で対応するべき

BFF設計・実装は誰がやるのか

フロント側かサーバー側か別にチームを立てるのか。
Node.jsまで書いてWebフロントエンジニア

クエリ型APIにBFFを構成する場合の良し悪し

Githubの例が好例。
RESTfulなAPIを提供しつつ、効率的に呼び出すためのGraphQLを双方提供している。

開発後期で問題になるケース

APIレスポンスの値をBFFでいじる事はある

BFFに対する考え方・使い方のアプローチ

  • 後から足せる、設計を先延ばしにする手段として
  • レガシーなシステムをリアーキテクトする手段として
  • 疎結合を与えることで、フロント側にも自由度を与えるアーキテクチャ・考え方として

メモ

ステッカーを盾形にするといい感じだなぁ、と見てて思った。カッコイイ!
今度出す時に採用したいですね、コレ。
OK キャンセル 確認 その他