BFF

Back-end for Front-end

Web 1.0

服务端返回 html

Web 2.0

服务端返回json,实现前后端分离

微服务

  1. API Gateway 网关分发请求

后端有时需要准备力度很细的数据返回，这个就要求前后端频繁沟通。有一些场景，后端又需要构造各种级联表单，以致微服务之间调度频繁；
而微服务的本质是清晰的界限上下文，因此在某些场景下这种设计会导致领域建模变得较为复杂

  1. CORS 前端跨域请求

前端分层和建模是最近比较流行的设计趋势

BFF

将组装、聚合、裁剪这部分业务单独拎出来，组成一个叫Back-end for Front-end的中间层
服务器设计 API 时会考虑客户端的使用情况，并在此层直接进行业务逻辑的处理和转发，又称为用户体验适配器

本质：nodejs，能做请求转发和数据转化
实现：Graphql的服务，对前Restful、对后RPC的实现，还可以在BFF上加cache、鉴权等等操作

BFF设计

优点

  • 前后端彻底分离，即便后期微服务迁移，无需改动前端代码
  • 业务更向前靠拢，琐碎的api由前端开发决定，更适配前端框架
  • BFF可以自开 mock,插件可以自动生成 api 文档
  • 后端更清晰的服务边界，只需要提供粗粒度的接口

缺点

  • 增加了系统的复杂度
  • 中间层转发增加请求延迟
  • 需要保证端对端的测试
  • 必须随时准备好后端异常请求
  • 增加开发成本

使用场景

SSR -> 同构
服务接口的聚合、裁剪、透传（GraphQL）

扩展

康威定律

设计系统的组织其产生的设计等价于组织间的沟通结构
如果系统架构不支持，你无法建立一个高效的组织

  1. 组织沟通方式会通过系统设计表达出来

  2. 时间再多一件事情也不可能做的完美，但总有时间做完一件事情

  3. 线型系统和线型组织架构间有潜在的异质同态特性

  4. 大的系统组织总是比小系统更倾向于分解

    自管理

奥卡姆剃刀原则：——若无必要，勿增实体

  1. 需要假设最少的解释往往是越接近真相的解释。
  2. 如果有某个条件是不能被我们感知和检测到的，那么和没有这个条件根本就是等价的。

Airbnb规范

WebAssembly

c/c++ 编译成 js