APIGatewayパターンとBFF
マイクロサービスアーキテクチャでよく利用される、APIGatewayパターンとBFFについて調べたのでメモ
なぜAPIGateway?
マイクロサービスアーキテクチャでシステムを構築する場合、複数のサービスを組み合わせる形でシステムが構築される。
たとえば、ECサイトの商品詳細を表示するために、商品情報サービス、レコメンデーションサービス、レビューサービスを利用する必要がある、ということ。この場合アプリケーションの実装によっては並行リクエストを行うのが難しかったり、モバイルアプリケーションの場合は帯域の問題も発生する。（その他にもいろいろあるが割愛）
そこで、アプリケーションとサービスの間にAPIGatewayというレイヤーを追加することで問題を解決する。
APIGatewayの実装
単純な場合はこの図のようになって、全てのアプリケーションからのリクエストを１つのAPIGatewayで受け付ける。
ただ、これはOSFA(one size fit all)APIというアンチパターンになってしまう可能性がある。アンチパターンかどうかは微妙なところだが、Netflixのblog( Embracing the Differences : Inside the Netflix API Redesign - Medium ) でOSAFには限界があるという記述がある。
そこでBFF
アプリケーション毎にAPIGatewayを用意し、それぞれのAPIGatewayは各クライアント専用のエンドポイントを定義する。
SPAの文脈でNode.jsを置いてそれをBFFと呼んでいることがあるが、マイクロサービスアーキテクチャのBFFとはちょっと違うのかなーという印象。例えばRailsなどのモノシリックのWebアプリケーションを、Node.js + RailsAPIに分割する場合、SPAでいうとNode.jsがBFFになるが、マイクロサービスアーキテクチャのBFFは、Node.jsとRailsAPIの間にAPIGatewayを置くのがBFFになる、はず。（多分
感想
APIGatewayといえばAWSのAPIGateway、BFFといえば、SPAの文脈のサーバサイドJS、というイメージが強く、間違って認識していたことも多かったので改めて調べなおしてよかった。
ソースはここ
