在后端开发中如何设计优秀的接口
发布于 9 个月前 作者 luanxuechao 1708 次浏览 来自 问答

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

12 回复

从我之前的 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

回到顶部