是按照页面设计接口,还是设计Restful接口,让前端去拿不同资源下的数据,实际工作遇到。

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

背景

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

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

思考

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

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

回答你的问题本身:

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

image.png

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

来自酷炫的 CNodeMD

@atian25 感谢在楼上,哈哈,

来自酷炫的 CNodeMD

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

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

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

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

来自酷炫的 CNodeMD

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

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

@hewentaowx 是的。。

来自酷炫的 CNodeMD

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

@Matrixbirds 。。。。。

来自酷炫的 CNodeMD