
120
このようにサービス分割をした上で、クライアントのユーザーイン
ターフェース(Webブラウザまたはモバイルアプリ)からのリクエスト
を受け付けるAPIゲートウェイを設けています。ユースケースによっ
ては経費精算サービスのAPIだけでなく証憑管理サービスや不正検知
サービスへのAPIを呼び出すこともあるので、それらのAPIの隠蔽や
集約を行う層を置きました。
Column
BFFパターン
ケーススタディの非機能要求の中に、以下のマルチデバイス対応に関する
要求がありました。
●
[REQ-24]申請や承認やスマートフォンやタブレット端末からも行う
ことができる
最近のフロントエンド技術は多様化が進んでいます。React Nativeや
Flutterのようなマルチデバイス対応、クロスプラットフォーム対応のフレー
ムワークもありますが、クライアントのデバイスごとに最適な技術を使用し
てアプリケーションを構築することも少なくありません。
APIゲートウェイが複数のクライアントアプリケーション向けのAPIをす
べて提供しようとすると、それぞれの技術要件に適した専用のエンドポイン
トを多数用意することになり、肥大化してしまいます。
これを解決するために、クライアントアプリケーションごとに専用のAPI
ゲートウェイを用意するのが、BFF(Backends for frontends)パターンと呼
ばれるものです。
ケーススタディにBFFパターンを適用するなら、図3.3.11のようにWeb
アプリ用のBFFとモバイルアプリ用のBFF ...