入る前に
こんにちは、最近インフラ作業ばかりだが、もっとスペシャルリストになりたいキムと申します。
最近チームで、BFFパターンについて話が出て上がったが、自分はキーワード自体は前から効いてましたが、具体的になんのものなのか、よくわからない状態でした。
今回、すごく理解しやすく説明してくれる外国の記事を発見して、概念を理解することにすごく助かったのでこの場を借りて、共有したいと思います。
ソフトウェア構成の進化
完全に分産されたアーキテクチャが実行される前には、一般的に一つ以上のレイヤーでアプリケーションを作成してきました。
階層は高度に結合されましたが、独立したアプリケーション構成要素と言えます。 サービスとは異なり、1つのアプリケーションでのみ使用するようになっている点が結合しているといえます。 同一プロセスの一部として実行されない方式から独立し、しばしば、同一のシステムでさえ実行されないことがあります。
このようなアーキテクチャはすごく複雑になるかもしれませんが、全般的には他のアプリケーションの間に線をいれて始まりと終わりのポイントがはっきり区分できました。
各アプリケーションごとデータのレプリカと共通ビジネスプロセスが重複され、時間がすぎるごとにデータを共有したり、ビジネスロジックを再利用できるアプリケーションが必要になっていくことで、最初かなりシンプルだったアーキテクチャは少し複雑になり始めました。
より多くの再利用と、統合が必要になっていくことで、アプリケーションを設計してた集団的な考え方として、サービスと言う少し抽象的な概念にたどり着きました。
上記のアーキテクチャのポイントは再利用可能なサービスが提供する柔軟性です。 結果として、このようなアーキテクチャに基づいたアプリケーションを構築することについては、以下の問題が顕在化しました。
1.必要なサービス選択
2.サービスを呼び出すのにいくつかの接続コードが必要
3. データから得たデータをエンドユーザーになじみのあるデータに併合
4.最終ユーザーが使用できる方式でデータのレンダリング
同時にコンピューターやインターネットはますます人気を集めており、社員やシステム運営者とコミュニケーションをとっていた顧客たちがアプリケーション自体と直接相互作用し始めました。
デザイン思考とユーザー経験に関する研究は、ユーザーをより効率的に作り、ユーザーが理解できるより豊かで有用な環境を作ることに焦点を合わせ、複雑なユーザーインターフェイスから脱するために努力していました。
実はウェブサイトの説明書を読む人はほとんどいないと思います。 ユーザビリティの良い環境を提供するためには、豊富な経験とデータが必要であり、これは様々な出処の情報を収集することを意味します。
LOB（Line-Of-Business）システムのためのユーザーインターフェイスの代わりに、次第に多くのユーザーインターフェイスが独自のアプリケーションに変わっていった。 これらのアプリケーションは、主にJSP、PHP、ASP 等で作成され、このコードは、ユーザインタフェースとアプリケーション別の百円ロジックをすべて含んでいる。
モノリシック（Monolithic）の終わり
上に述べた簡易な例は、現代の技術組織がアーキテクチャを発展させてきた流れとさほど変わらないと思います。
2011年SoundCloudのウェブサイトは下記のようでした。
すべてビジネスロジックと、処理が一つのシステム内に存在してました。
SoundCloudの場合Back-endシステムをすごく簡単な形として考えてました。
上の考え方は大きい箱を一つのモノリシックで作り出したものになります。実はこの大きい箱な下記のように構成されてます。
本当は、SoundCloudは一つのシステムをもってるわけではなく、複数のものが存在するプラットフォームをもっており、このアーキテクチャに対する問題点を発見し、マイクロサービスを利用することを決めました。というわけで、下記のようにアーキテクチャを変更することになりました。
バックアンドサービス抽出に成功しましたが、このバックエンドは相変わらずすべてのRequestが集中する重要な経路のままでした。
アーキテクチャ変更の主な動機は新機能のリリース時間を短縮することでした。 そして、この修正によって発生するボトルネック現象が致命的であることがわかりました。
ユーザインタフェースがどれだけ頻繁に変更されるかを考えると、既存のモノリシックコードを抽出することは、生産性を高める直観的な方法でありました。
その上で固有の構成要素からUI 階層を抽出し、共用API からデータを取り込むようにしました。
2011年にこのようなアーキテクチャの変化が起きた時、ほとんどのユーザーがウェブを利用しました。 FredWilsonのような人々が予測した通り、結局これは変わり、私たちのユーザーが基盤はWebインタフェースよりもモバイルアプリを使い始めました。
Soud Cloudは、AndroidとiOSのためのモバイルクライアントを提供しました。既存のウェブアプリケーションとPublic APIを利用してモバイルクライアントを支援してきました。
SoudCloudの課題
自作のAPIを元にしてプロダクトを構築するのは、APIが高い品質を維持して、常に最新状態を確認できる最も良い方法として認識されてます。SoundCloudはこのアプローチ方法に対していくつかの問題点が発見されました。
まずは、プロダクト開発に対する根本的な問題でした。
単一プロフィールページを作るためには下記のような複数のAPIを同時に呼び出さなきゃいけいない。
- GET /tracks/1234.json (作成者）
- GET /tracks/1234/related.json（関連Track情報）
- GET /users/7123.json（Trac作成者情報）
- GET /users/me.json（現在ユーザー情報）
- その他…
上のAPIたちの情報を組み合わせてユーザープロフィールページを作成します。上のアーキテクチャではネットワークボトルネックがあって、新しい機能を追加するたびに、すべてのクライアントが簡単に使えるように時間をかけなきゃ行けなかったです。
Front-endのためのBack-end (BFFの登場）
上のアーキテクチャを構成してから1年後、SoundCloudは新しいiOSアプリケーションを開発するための準備を進めてました。これは、ユーザー環境を変化させる大規模PJであり、アーキテクチャチームは上の問題たちが、PJに邪魔ものになることを認識しました。アーキテクチャを再び悩まなきゃいけないところでした。
Googleからの最初の提案ソリューションはモバイルやWeb用で異なるAPIを使うことです。 このアイディアはクライアントがAPIを所有しているチームを持っていれば、相互間の調整が必要ではないため、はるかに早く動かせるというものです。
究極にコードを単純化し性能を向上させています。 BFFはアプリケーションのAPIではなくクライアントプログラムの一部だということを発見しました。
結論
SoundCloudは、生産性をさらに向上させる方法について研究し始めました。 すべてのアプリケーションに同じユーザプロフィールページが存在したため、すべてのBFFがデータを取得して併合する過程で、多くの重複コードが存在していました。 それでAPIをひとつにしてビジネスロジックを提供するサービスが必要でした。
時間のたつにつれてこの様な状況がどんどん発見されていき、アーキテクチャはこの部分を包容しながら変化していきました。
最後に
いかがでしょうか？
私はこの記事を読んで、どんな背景で、どのような考え方から、どういった目的をもってからBFFが登場したのかをよく説明してくれたと思います。
なので、みなさんもご自分のPJにBFFの導入につて考慮するときにどんな目的をもってどのような問題を解決したくてBFFのキーワードが出てきたのかをよく考えてみてください。
原本はこちらです。興味ある方はぜひ読んでみてください。
https://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html