从我之前的 Slide - Egg & Node.js 从小工坊走向企业级开发 摘抄部分，如下

背景

这是一个微服务架构下，企业开发经常会遇到的一个困惑：

• 本质是服务下沉与用户体验灵活性的矛盾
  • 服务趋向稳定，倾向下沉
  • 用户体验趋向不稳定，诉求服务的高度灵活与定制
  • 不同的设备对 API 有不同的诉求
  • API 灵活性对服务开发者要求太高
• 服务层 API 相对稳定，体验层 API 经常变化
• 服务端设计的接口究竟是面向 UI 还是只是通用服务？

思考

我们的解读是：Backend for FrontEnds 模式。

• 最重要的是：服务自治，即谁使用谁开发，吃自己的狗粮。
• BFF 根据团队的技术栈来选型：Java / Node / Ruby / PHP / …
• 我们的选型是：在我们业务场景中，相对较优，生态最活跃，最能被前端接受的 Node.js 。

回答你的问题本身：

• 后端服务保持微服务化，追求领域模型的适当抽象和纯净。
• 中间增加 BFF 粘合层，由对应的使用者开发并维护。吃自己的狗粮。
• 目前流行的 GraphQL 可以视为是一种通用型的粘合层。
  • 可以由后端提供并维护此类通用服务，端使用者仅需定义指定的语法即可消费。

感谢。。。最近真的很纠结，哎，没办法，小公司没有完整的体系。。。

来自酷炫的 CNodeMD

@atian25 感谢在楼上，哈哈，

来自酷炫的 CNodeMD

@luanxuechao 其实还好，就是逻辑概念上要分清，Backend 层 和 BFF 层要独立开，可以是由后端来同时维护这两层，但最好要独立开，这样方便维护和分层。

@atian25 是的 应该 现在我们是数据层 和视图层 没有分开 所以导致对接时这种境遇。。。

方便前端一点的话就是按页面来设计。 但是当你的api被多种客户端(web网页, 手机app)应用时，按照页面设计就不好了。

@jokerapi 是的，主要是因为有各个端

来自酷炫的 CNodeMD

按照ui设计感觉并不好 业务需求不停在变 ui也跟着需求变 我觉得还是按照服务需求设计好一点吧

我们是分两层，底层是服务设计，不考虑业务需求，上面加一层专门对接业务的。 GraphQL挺适合这种场景的，但还没有尝试。

@hewentaowx 是的。。

来自酷炫的 CNodeMD

面向舒适度编程。服务端扛得起怎么舒服怎么设计。

@Matrixbirds 。。。。。

来自酷炫的 CNodeMD