基于 GraphQL 的 BFF 实践

🚀 优质资源分享 🚀

学习路线指引（点击解锁）	知识定位	人群定位
🧡 Python实战微信订餐小程序 🧡	进阶级	本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。
💛Python量化交易实战💛	入门级	手把手带你打造一个易扩展、更安全、效率更高的量化交易系统

随着软件工程的发展，系统架构越来越复杂，分层越来越多，分工也越来越细化。我们知道，互联网是离用户最近的行业，前端页面可以说无时无刻不在变化。前端本质上还是用户交互和数据展示，页面的高频变化意味着对数据需求的高频变化。在绝大多数场景中，页面数据都来自于服务端，因此对页面变化的感知势必会传递到服务端，而服务端是要做业务能力沉淀的，需要逐步完善领域模型，沉淀商业逻辑，所以就产生了一个矛盾，一个领域能力沉淀和高频数据变化的矛盾。

为了解决这个矛盾，在业界不断的探索实践中，逐渐在架构层面演化出一个 BFF 层，Backend For Frontend，顾名思义，专门响应前端需求的服务端。

我们知道，不同的团队，因为其面临的业务场景不同，在面对相似问题的时候，通常解法也会不同。本文会结合笔者之前的 BFF 实践经验，介绍一种基于 GraphQL 的 BFF 实现。

BFF

Backend For Frontend 在 15/16 年的时候开始逐步受到关注，经过多年的实践和发展，业界已经有了非常多的解决方案，各种技术栈的实践都有。个人认为，要想准确的理解 BFF，需要抛开具体的技术细节和业务场景，从团队协作的角度来看。

BFF 的诞生是为了解决服务端领域能力沉淀和前端多样化的数据需求之间的矛盾的。因此，凡是有助于减少前端和服务端之间的冲突，降低开发成本的，都属于 BFF 讨论的范围。

我们从下面几个方面讨论一下 BFF 的适用场景。

• 数据聚合裁剪

通常，为了降低页面对服务端开发的影响，服务端会单独分离出一层 API 层，专门响应页面需求。但是由于缺乏一些明确的约束和指导，由于各种各样的原因，慢慢的 API 层中会出现一些业务逻辑，导致 API 层与业务层边界模糊，影响到对页面需求的响应。

• SSR

现在提到 SSR，通常会理解成基于 NodeJS + React/Vue 的服务端渲染。其实，在早些时候，还有基于模板的实现，知名的模板引擎有 Apache Velocity（Java）、