SoundCloudは最近、Backends for Frontendsパターンの実装に関する記事を公開した。これは、2013年に導入され、マイクロサービスベースのアーキテクチャへの移行を開始するところだった。SoundCloudの技術リーダーであるJorge Creixell氏は、このパターンには重大な欠点があると結論付けた。その利用者は、その利点を享受しながらも適切に管理しなければならない。
Backends for Frontends(BFF)パターンは、各クライアントの特定のニーズに合わせて調整されたゲートウェイサービスを構築することで構成される。クライアントは、フロントエンドアプリケーションあるいは外部インターフェイスかもしれない。SoundCloudでは、BFFサービスがレート制限、認証、ヘッダーサニタイズ、キャッシュ制御などのAPIゲートウェイの役割を担った。
著者によると、結果として得られるサービスの数が増えると、「それが複雑さと重複をコントロールできるサービスアーキテクチャの一部でない場合に、問題の原因になる可能性もある。」機能の統合は各BFFサービスに実装される傾向がある。そのため、認証などの共通事項の実装が重複し、時間の経過とともに枝分かれするのだ。
著者はSoundCloudで、複雑なクライアント側ロジックをBFFにプッシュする傾向を確認している。バックエンドへのこのロジックのシフトは場合によってはうまくいくかもしれない。しかし、著者はそれが問題につながる可能性があると指摘している。ページが割り当てられたコレクションのすべての部品を収集して、サーバ側で1つのリクエストに返す例を挙げて、最終的にどうなるかについて、様々ある結果の中で「システム全体をダウンさせる可能性のあるファンアウトストーム」につながる可能性があると述べている。
BFFサービスに固有の特殊化により、SoundCloudでは、同期ポイントや困難な妥協を必要とせずに、各クライアントタイプに都合のよいものに合わせてAPIを最適化することができた。このパターンでは、さまざまなクライアントとインターフェイスが分離されているため、SoundCloudで復元力の向上と開発のペースの向上のエクスペリエンスを得られた。
著者は、デバイスまたはインターフェースタイプごとに複数の専用APIゲートウェイを備えたSoundCloudのBFF実装は、集中型APIゲートウェイやGraphQLなどの他のアプローチやテクノロジーとは異なると考えた。さらに、フロントエンドエンジニアとバックエンドエンジニアの間の広範なコラボレーションが必要となる。したがって、「クライアント開発者の完全な自律という考えは単なる幻想なのだ」。
この分野の他の専門家は異なる見方をしている。たとえば、ソフトウェアアーキテクトのGlenn Engstrand氏は、InfoQで、GraphQLはBFFサービスの賢明な選択であり、このサービスはオーケストレーターとして動作し、フロントエンドチームが所有する必要があると主張している。
SoundCloudのシステムアーキテクチャは、BFFパターンの実装に関連する問題が特定された後も進化を続けた。その進化について詳しく説明した記事が他にもSoundCloudのBackstageブログに公開される。