モバイルデバイスを使ったWebエクスペリエンスは，その小さな画面や限られたデータプラン，要求数を少なくする必要など，多くの点でデスクトップWebブラウザとは異なっている。さらに，サイズ的には少ないが内容の違うデータが必要である上に，バーコードリーダ経由など独特のインタラクションを提供する場合もある。これはつまり，モバイルデバイスのための機能をAPIバックエンドに追加する必要があるということだ - Sam Newman氏はブログ記事でこのうように指摘した上で，デバイスによって異なるユーザエクスペリエンスのミスマッチを扱うためのAPIバックエンドのパターンを解説している。
Thoughtworksの開発者である氏が提案するソリューションのひとつは，すべてのタイプのユーザインターフェースを提供する汎用APIバックエンドを構築することだ。しかしニーズが大きく異なるため，この方法の実現にはバックエンドへの機能追加と複雑性の増加が伴う。さらに，すべての変更で全デバイスをサポートする必要があるため，デプロイメントプロセスのスローダウンという形のボトルネックになる可能性もある。汎用目的のバックエンドを採用する場合，バックエンド専任の特別なチームを編成する場合もあるが，Newman氏の経験ではこれが問題となる可能性がある。他チームからの要求に優先順位を付けなくてはならないフロントエンドチームにとって，交渉の必要な別チームがさらに増えることになるからだ。
Newman氏が紹介するもうひとつのソリューション例は，ユーザエクスペリエンスごとにひとつのAPIバックエンドを用意する方法だ。概念としては，ユーザ向けアプリケーションが２つのコンポーネントで構成されることになる。ひとつがクライアント側で，もうひとつがサーバ側という，BFF(Backend For Frontend - SoundCloud開発中のPhil Calçado氏による造語)である。
BFFを採用する場合，通常は特定のユーザインターフェースと強く結び付けられて，両方を同じチームがメンテナンスする。異なるプラットフォームの同タイプのユーザインターフェース，例えばAndroidとiOSを扱うような場合には，Newman氏によれば２つのアプローチがある。ひとつのBFFで両プラットフォームを扱うか，あるいは各インターフェース毎のBFFを用意するか，である。
Newman氏が推奨するのは，各プラットフォーム毎の厳密なBFFモデル，つまりAndoidにひとつ，iOSにひとつという方法である。このアプローチによるリスクは，同一タイプのアグリゲーションや同じダウンストリームサービスのコードのように，BFF間で作業の重複が多数発生する可能性のあることだ。それでも氏は，プロセスバウンダリを越えているため，これは大きな問題ではないと考える。汎用的な集約型Edge APIへの統合については，そのようなモデルは動作保証に時間を要する上に，コードの極端な肥大につながる点を氏は警告している。
AndroidとiOSに対してひとつというように，クライアントタイプ毎にBFFを使用する方法は，SoundCloudで採用されたアプローチである。氏はこのアプローチに対して，クライアントタイプが増えることによるBFFのコード拡大を懸念点として指摘する。
同じくThoughtWorksのLukasz Plotnicki氏は先日，モノシリックなRailsアプリケーションからマイクロサービスへの移行においてBFFを使用した，SoundCloudでの開発を取り上げたブログ記事を書いた。
同社の最新のTechnology Radarでも，追求の価値のある技術としてBFFが言及されている。