大家工作中的前后端是如何合作的？如何减少接口变更？

[crclz]

引言

首先我大量查阅了 V2EX 、知乎的讨论，发现前后端主流做的合作方法都是：

1. 前后端先商定一份接口文档（如果自动化一点，那么可以写一堆未实现的方法，然后用 swagger 生成文档）
2. 接着，前后端并行地开发，后端实现接口，前端依据接口文档进行开发
3. 前后端联调

问题

但是，在实践中，我发现了一些问题：

起草文档阶段往往是非常短暂的。在这个过程中，开发者无法了解系统全貌，自然无法确定完接口列表。随着前端和后端的开发工作的推进，这些忘记的接口、需要修改的接口才逐渐暴露，这会增加前后端合作、沟通的时间成本。

那么，在起草文档阶段，是否有一个系统的方法，来确保最小化这种需要增加、修改的接口数量？

[pmyile]

交互评审的时候 走一遍 接口交互

[gz911122]

在起草文档阶段，是否有一个系统的方法，来确保最小化这种需要增加、修改的接口数量 :

后端先定好技术方案, 再商议接口文档,变更会小很多.

[pushback]

不改需求不就没修改了么。

[hantsy]

对于开发阶段变化太快了，又臭又长的文档根本不可能用来做约束。

CDC 模式（ Consumer Driven Contract ）是一种很好的用于 API 协议开发 Pattern，API Producer 和 Consumer 之间先定好协议 Contract，生成 Stub 之类的，再分开开发实现，最终两边都是要通过相关的 Contract 测试。

自己查看 Pact 使用，支持各种语言。

另外 Spring 下的 Spring Cloud Contract 也一样，对 Spring 生态支持一流，还可以定义 Message Broker 之间的协议，只是对前端语言框架支持不如 Pact 好。

[yidinghe]

前端只关注布局、风格、交互效果和响应性，内容通过后端发来的元数据渲染出实际的界面元素，比如表单有哪些字段等等。

[Kilerd]

果然会出现 spring cloud contract，那玩意写起来简直是灾难，然后团队无一例外的转向了 moco

[rapiz]

突然想，有没有这样的工具，在开发初期可以用图形界面之类快速设定接口格式，可以生成 openapi 文档，然后向前端提供后端的 mock 代码，向后端提供对应框架自动生成的接口代码。

[carbrokers]

歪个楼，做过一个项目，后端把数据库所有能取到的字段全部给前端了，后期完全不需要接口变更，所以后续的开发任务后端完全没有参加过。。。

[skypyb]

产品：新加一个小需求 /小改动

[xiangyuecn]

前后端靠背坐：
前端要数据转身拍拍后面那家伙：兄 di 给数据🎉
后端改了接口转身揉揉后面那妹纸：接口字段又改了哈🤣

有争论？互殴解决

[faceRollingKB]

个人经验：这种问题几乎无法避免，所以技术上我选择用 typescript 开发，方便日后改接口定义，另外如果接口定义问题比较大(概率小)，通常涉及到组件、模块的重构，所以我选择用 ng 框架，重构代价小

[Jackeriss]

graphql

[chendy]

@Kilerd #6 +1 spring 家两个东西 restdoc 和 contract 都是理想很丰满，用着贼难受的东西

[lenqu]

可以参考我之前未做完的一个的东西，API 接口的一个中间件，在后端接口之上进行统一规范化，后端只完成最小单元接口实现，中间件进行整合提供服务

有需要的联系我哦！！！一起做

[Kilerd]

@lenqu #14 graphql ？ 先解决 N + 1 的问题再说吧。

[Foxkeh]

@carbrokers 你说的"所有", 包括用户的密码字段吗😄

[malusama]

@Kilerd DataLoader

[lenqu]

@Kilerd 如果已有的后端接口可以实现，那么直接扩展即可，如果没有，在已有的单元接口之上再进行扩展，保证后端开发代码量最小

[Justin13]

上 GpaphQL

[hantsy]

@chendy 这两个东西只要你的团队一直坚持写测试，一般不会有什么太大的问题。restdocs 我之前一个项目下来一直在用，用于 API 开发文档生成。

Spring Cloud Contract 有一定局限性，对于全部后端 Microservice 中 service 2 service 互操作的测试，优势很明显。但前后端调用，虽然官方也一直在加强其它实语言支持，也提供了 Nodejs 与 Java 项目结合的例子，但是与前端结合的时候远不如 Pact 舒服。