なぜ振り返るのか
マイクロサービスもBFF(Backend for Frontend)も最近出てきた。という話ではないです。
ただマイクロサービスの推進、もしくはこれからやる必要があるサービスというのは
まだまだたくさんあると思ってます。
何より自分が携わるサービスでまさにマイクロサービス化が進んでおり、
同時にネイティブアプリの開発も促進されている状態にあり、
BFFの導入検討が必要であるために振り返ってみることにしました。
マイクロサービスとBFFの兼ね合いとは
モノリシックな状況において提供されるAPIは必要なリソースが集約されているケースが多いため、
API単体で見ると実はフロントエンド側の画面構成に対して、
必要なデータがすべて返却されるAPIがあったりもします。
マイクロサービスが進んでいくと各サービスの連携がAPIベースになるのと、
ドメイン分析して分離が進むとはいえ、多くはデータが切り離されていくため、
リソース単位といったAPIが提供されていく。ということが増えていきます。
(正確にはもっと細かく層が分かれたりと、色んなケースがあると思いますが)
この状況下において起きる懸念としてクライアントサイドでは
画面を構成する要素として複数のリソースが必要な場合に
今までは1つのAPIで提供されていたものがリソース単位に分離されたAPIを
クライアント側でそれぞれのAPI参照を行い処理を行う必要があるケースが生まれます。
これ自体は画面構成によっては最初の描画に必要なリソースをまず取得する。
なども可能となるため必ずしも悪いことばかりではないですが
クライアントサイドに関しては処理そのものや、利用するAPIが増えることで
それぞれのAPIの変化に対する考慮自体も増えることになります。
このフロントエンドの仕様に伴う複雑なAPI処理と疎結合な状態を担うために
Backend for Frontendの導入が求められるケースが出てくると考えております。
BFF導入のメリット
フロントエンドのビジネスロジックを1つのシステムに集約できる
例えばiOSアプリ、Androidアプリで共通のBFFを利用するのであれば
両方のアプリで実装必要であったロジックを一箇所にまとめ、そこの改修だけに抑えることが可能になります。
また不具合対応もBFF側で巻き取れるケースも出てくるため、
ネイティブアプリのアップデートなしで問題解決できます
アプリとAPIの疎結合な状態
マイクロサービス化していても既存のAPI仕様を大きく変更したり、
V2などのAPI提供が必要になることがあります。
この時、ネイティブアプリの場合はV1のAPI利用などをなくすために強制アップデートなどが必要となりますが、
BFFがその変更を吸収し、クライアントサイドに対しては互換性を保つようにすることが可能となります。
ゲートウェイの集約
その名の通り。サービス単位でクライアントにAPI提供する場合、
それぞれがゲートウェイを考慮する必要がありますが
BFFがある場合はクライアントとBFF間のゲートウェイの考慮で済むと思います
BFF側の問題でのキャッチアップ
ネイティブアプリで問題が起きる場合、そのエラーがアプリ側の実装によって起きてるのか、
APIより後ろ側で問題が起きてるのかを切り分けるのに時間がかかったり、が難しいケースがあると思います。
BFFが挟まることでアプリ→BFF間の問題か、BFF→API間の問題切り分けがしやすくなります。
BFF導入のデメリット
レイテンシーの増加
これはマイクロサービス化でもよく言われる問題ですが、
BFFを挟むことも当然レイテンシーは増加することになります。
クライアント側でサーバ開発の領域が増える
これは組織の切り分け次第かもしれませんがシステムが増えるので当然そこの開発・運用は発生します。
それを行うためのスキルや人員はどうしても必要となります。
人員、組織を分離して構成したとしてもクライアント側の仕様、要件の理解や密な連携は必要となります。
アプリ側の不具合吸収によるBFF側の保守コストの増大
設計次第ではありますが、常にクライアント側のバージョン情報、OS情報などを受け取っておくことで
柔軟にバージョン、OSに合わせた保守対応が可能となり、
アプリのアップデートを行わずに問題解決できるメリットがある。と同時に
BFF側で複雑なバージョン、OS判定処理などが増えるリスクも起きます。
BFFの負荷考慮
BFFが負荷で落ちたり遅延が生じると、クライアント側全体も動かなくなってしまうリスクが生じます
そのため、負荷に対しては慎重に検証、考慮する必要がありますし
オートスケール、冗長化、マルチAZを考えるだけでなく、
ある程度の単位でAppなどを分ける設計。などを多く考える必要があります。
BFFの技術選定
フロントエンド側での実装が多くなるはずなので、そことの親和性が高い言語選定が良い気がしております。
とはいえ複数APIの処理を行う上では並列処理の強さが必要であることは否めないと思います。
となるとNon-Blocking I/Oなどは意識する必要がある気がします。
また静的型付けの言語を採用することでBFFとAPI間で型の問題が綺麗になってる方が
クライアント側でより使いやすい形でAPI提供ができるのではないかと思います。
こうなってくるとGo、TypeScript辺りの採用が、自分の中ではイメージとして強くなりました。
サーバサイドKotrinも親和性が高く要件も満たしていそうなので良いのかもしれません。