BFFアーキテクチャについて

初めまして！3月に入社しましたコッシーです。

外出自粛モード真っ只中となってしまっていますが、みなさまいかがお過ごしてしょうか？

最近は心地良い気温で出かけたいな〜と思いつつもひたすら外にでないことに徹しています。

そしてついにブログ当番！！

さて・・・何を書こう(^_^;)

５分程度考えて・・・更に５分・・・
閃いた！！
Web系の開発をしていて、また最近よく聞くようになったので今回はBFFアーキテクチャについて少し説明をしたいと思います。

Web系の開発をされている方であればご存知の方が多いと思いますが、

お付き合いいただければと思います。

BFF(Backends For Frontends)ってなに？

マイクロサービスアーキテクチャ設計の一種で、

フロントエンドとバックエンドの仲介役を担うサーバーゲートウェイ(API Gateway)になります。

マイクロサービスの導入をするとAPIサーバーが多くクライアントのリクエスト数が多くなったり、PC用とモバイル用で返す項目を分けたい場合等、最適化しにくく複雑化してよく課題に上がることがあるかと思います。

そこでフロントエンドとバックエンドの間に各クライアント(PC、スマホ等)毎にBFFを介すようにすることで、クライアント側からはBFFに対してのリクエストのみを行う形になり、BFFからAPIへのリクエストする形になります。

このようにクライアントとバックエンドの仲介役を担うサーバーをBFFと言われています。

BFFを導入することのメリット/デメリット

BFFを導入することによる大きなメリットとしては、フロントエンドとバックエンドの責務を分離することが出来ます。

モノシリック環境下だと例えばバックエンドの進捗が遅れるとフロントエンドの開発ができないといったことがありましたが、UI/UXの部分をフロントエンドが包括して担当することになり、バックエンドはデータ操作の処理と綺麗に責務を分離することが出来ます。

他にもBFFをSSR(Server Side Rendering )とした場合、SEO(Search Engine Optimization)による検索エンジンの最適化や、SSG(Server Side Generate)とした場合は画面読み込みの高速化、クライアント毎に取得するデータの最適化等のメリットがあります。

しかしBFFを導入することでBFFが何らかの影響で停止した場合はサービス全体に影響が受けることになりますので注意が必要です。

BFFのアンチパターン

アンチパターンについても少し触れておこうかと思います。

BFFにおいてのアンチパターンは主に3つあります。

スパースコミュニケーション：

フロントエンドとバックエンドのコミュニケーションが疎になることで、

双方のAPI仕様の認識に齟齬が出ることで発生します。

例えばエンドポイントの違いや、レスポンスの過不足等があります。

ファットフロント：

BFFの処理としてバックエンドで行っていたSSRやセッションマネージメント等の処理を委譲する形になることが多いと思います。

しかしBFFに委譲させすぎてしまうとBFF側の負荷が高まり性能が悪くなる可能性があります。

ビッグバンジョイント：
フロントエンドとバックエンドの責務を分離して開発することが出来ますが、BFFとAPIとの結合を後回しにして、全て一度に結合させてしまうことです。
みなさんもお仕事で何でも最初から想定通りにうまくいくことはほとんどないかと思います。
大体はコツコツ修正、改善して、ようやく当初の想定の動きであったり結果が出るのと同じようにBFFとAPIを徐々に結合させていくことが重要です。
 

どちらも原因としてはフロントエンドとバックエンドでコミュニケーションが疎かになることが大半です。BFFを導入する場合はフロントエンドとバックエンド間でコミュニケーションを密に取り、BFFとしての役割をしっかりと明確にすることが重要です。

終わりに

色々なアーキテクチャを知っておくと意外と役立つことがあったので今回はBFFについて書いてみましたが、いかがでしたでしょうか？
少しでもご興味を持っていただけたら幸いです。
リモートワークで自宅にいることが多いかと思いますが、適度に手洗いやアルコール消毒をして、コロナウイルス感染には気を付けてください！