# Backend For Frontend 前端模式的後端

### 起: 後端為microservice架構時，前端最單純就是直接與各服務溝通，「direct client to microservice communication」
- client 與服務高度耦合，不易維護
- 多個round trip，可能增加latency
- 安全性隱憂，Endpoints向外暴露
- Cross Cutting Concerns，相同邏輯橫切多個模組
### 承: api gateway 為一層proxy layer，除去原本前端對每個後端系統的高耦合性，並且減少network request
- 可以作為 Reverse Proxy
- Layer 7 的 Routing，使 Client Side 與 Services 解耦，達到關注點分離
- 便於轉移後端應用架構，如monolithic refactor to microservice
- request aggregation: 適量將通用邏輯跟功能放在gateway層，一般來說伺服器端的溝通延遲遠小於 Client Side，再者這個方式也讓程式更好維護與擴展
- Single Point Of Failure 的可能性
- 增加架構複雜度跟影響開發/維運效率

### 轉: 根據不同client種類，對同backend endpoint或有不同的資料需求(如內容或格式等)，仰賴此general purpose API backend 去分別處理造成架構混亂，並且不易擴展

### 合: Backend For Frontend(BFF)，根據不同裝置/需求建議獨立的 Gateway Proxy Server，達到「One Backend Per User Experience」
- api gateway 變化版，概念相同為作為中間層
- 易根據client調整api
- 專注特定種類的client，易維護與擴展
:point_right: BFF可能有重複的邏輯，可以考慮再拆成獨立的downstream services(perimeter)放在BFF與client之間

:book: **REFERENCE**
- [前端開發者該負責寫-api-endpoints-嗎]( https://medium.com/starbugs/%E5%89%8D%E7%AB%AF%E9%96%8B%E7%99%BC%E8%80%85%E8%A9%B2%E8%B2%A0%E8%B2%AC%E5%AF%AB-api-endpoints-%E5%97%8E-the-backend-for-frontend-pattern-bff-in-microservices-world-1368362c141c)
- [Pattern: Backends For Frontends](https://samnewman.io/patterns/architectural/bff/)
- [BFF @ SoundCloud](https://www.thoughtworks.com/insights/blog/bff-soundcloud)
- [Backend-For-Frontend using GraphQL under Microservices](https://medium.com/tech-tajawal/backend-for-frontend-using-graphql-under-microservices-5b63bbfcd7d9)
- [Backends for Frontends Pattern](https://aws.amazon.com/tw/blogs/mobile/backends-for-frontends-pattern/)