BFF（Backends For Frontends）実践における3つのアンチパターンと、その回避策

BFF（Backends For Frontends）実践における3つのアンチパターンと、その回避策：マイクロサービス/API時代のフロントエンド開発（終） マイクロサービス/API時代のフロントエンド開発に求められる技術の一つ、Backends For Frontends（BFF）について解説する連載。最終回は筆者の経験に基づいて、3つのBFFアンチパターンと、その回避策を紹介します。 実案件にBFFを複数回導入した筆者の経験に基づいて原因と回避策を解説 マイクロサービス/API時代のフロントエンド開発に求められる技術の一つ、Backends For Frontends（BFF）について解説する本連載「マイクロサービス/API時代のフロントエンド開発」。前回はBFFに関する5つのユースケースを紹介しました。 BFFはアーキテクチャのパターンの一種ですが、どんなときでも当てはまるものではあ

[Bulker]

“Backends For Frontends”

[len_prog]

“マイクロサービス/API時代のフロントエンド開発”

[zyxwv]

“BFFはUIのためのサーバであり、あくまで“表示”に関わる処理が主な役割" "バックエンドは「ドメインロジック」や「ビジネスロジック」と呼ばれる、UIに依存しない“コア”の機能を提供する”

[massa142]

“技術は揺り戻しを繰り返しながら良くなっていく」という流れからすれば、一度マイクロサービスによって疎結合へと傾いた流れはまた密結合に戻ることが考えられます”

[himanoa]

BFF特有の問題じゃなくてフロントエンドから見たAPIのユースケース掘り下げ不足に起因する問題が多い気がした

[yosuke_furukawa]

あ、そういえば書きました。

[efcl]

BFFからサーバ間でN+1問題が起きる話、"BFFはUIのためのサーバであり、あくまで“表示”に関わる処理が主な役割です。"

[daybeforeyesterday]

うーむ