8000 BFF · Issue #57 · ChelesteWang/FE-Review · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
8000

BFF #57

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
ChelesteWang opened this issue Apr 17, 2022 · 4 comments
Open

BFF #57

ChelesteWang opened this issue Apr 17, 2022 · 4 comments

Comments

@ChelesteWang
Copy link
Owner

API Gateway 与 BFF

image
有了 API Gateway 之后，它可以帮我们完成聚合之类的逻辑。不过有一个问题是前端可能有多种不同的类型，比如 PC 前端，Mobile 前端，它们的业务逻辑不可避免的会有各种各样的差异，如果在 API Gateway 中处理这些差异的话，那么会出现坏味道，为了解决此类问题，我们引入 BFF（Backend For Frontend），每一种前端都有属于自己的 BFF，用来处理专属于自己的业务逻辑，至于 API Gateway，则只处理鉴权，日志等公共业务逻辑。
@ChelesteWang
Copy link
Owner Author

image

@ChelesteWang
Copy link
Owner Author
  • 接口编排
  • 通用鉴权
  • 通用日志、监控

@ChelesteWang
Copy link
Owner Author

微服务治理

  • 服务发现（综合管理服务）
  • rpc 调用（减少数据调用）
  • 配置中心（减少运维配置）
  • 服务网关（综合能力，鉴权日志监控）

@ChelesteWang
Copy link
Owner Author

BFF
很多团队都会有 bff 这个解决方案，从传统的视角来看，主要有以下量个优点

api 网关：统一的数据接口处理，鉴权、参数、返回值、错误码等
数据裁剪：将后端的基础数据组合成适合前端渲染的数据结构
变化隔离：天然的防腐层，屏蔽服务接口的变化
技术迭代：ab test、流量灰度、渲染服务
那我们要思考如何让 bff 发挥更大的价值，更好的解决端的问题

性能视角：降低多加一层带来的链路损耗，服务资源的成本
业务视角：除了数据还能给端提供什么
下面是如何解这两个问题

利用 client 天然分布式的特点，结合 service worker 和边缘计算将 bff 更加前置
使用 graphql 消除请求和全局的缓存，减少不必要的 rtt，同时缓存可以进一步放在 cdn 数据库中

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ChelesteWang
0