从 API Gateway 看前端与后端

假如你是从很久以前就开始做开发，可能有经历过一段人人都是全端工程师的时光，在当时还没有所谓的前后端分离，基本上请求从客户端发送来后，伺服器会去处理所有事情，包含跟资料库打交道，以及把准备好的 HTML 返回给客户端。在这个架构下，因为所有东西都放在一起，不论是可扩展性或是故障时的隔离都会比较差。

要能比较有效做隔离，以及让程式比较好维护，后来发展出把不同的应用做拆分。举例来说，在一个电商的应用情境下，我们可以把使用者放到 /user、订单放到 /order 底下、物流放到 /logistic 底下，这样能做到基本的隔离，也可以让每个应用变得比较单纯，也会比较好管理。

但这种做法也有问题，假如这些仍都是放在伺服器端，这样与客户端仍是耦合的，这样要进一步拓展会比较困难。但是如果两者解耦合，又会导致前端可能需要大量请求多个不同后端 API，才能在前端组成所需的东西，这个问题在 Theo 的这个影片中有很生动的说明

要解决这个问题，BFF 由此而生。所谓的 BFF 就是指 Backend for Frontend，意思是给前端的后端，这边强调“给前端的”是对比“与前端解耦的”后端。BFF 在做的事情很简单，就是在前端与不同的后端 RPC 中间多加一层，然后让这层 BFF 去处理呼叫不同 RPC 来拿到所需的资料或者处理相关逻辑；而前端则不需用在自己呼叫一堆 RPC，可以只呼叫 BFF 就好。

但是这又会出现一个问题，假如 BFF 是为了特定的前端需求而有的后端，那假如是通用的前端需求，例如常见的验证 (auth)、限流 (rate limiting) 与平衡负载 (load balancing) 等，这不属于特定的 BFF，但又是每个 BFF 都需要的，这该由谁来处理呢?

在目前业界的普遍做法，是会交由 API Gateway 来处理，所谓的 Gateway 就是一个入口，在实际进到 BFF 前，会需要先经过 API Gateway 这个入口。举例来说，假如有个没权限的人想要呼叫某个 BFF，在 API Gateway 就可以先验证然后挡下来。

当演进到 API Gateway 的出现，上述过程中会发生的各种事就都能被有效解决，而我们可以有个可拓展、解耦，但同时又能为特定前端提供需求的架构。