小松建设官方网站,aso100官网,网件,江苏商城网站建设吐槽文一篇。契约的一些问题在实践前后端分离的这些年来#xff0c;已经诞生了一些技术与工具让前后端进行沟通#xff1a;契约的 Mock 服务#xff08;Mock Server#xff09;。用于模拟一个服务器#xff0c;为特定的接口返回特定的值。契约测试。对前后端协定的 API 进…吐槽文一篇。契约的一些问题在实践前后端分离的这些年来已经诞生了一些技术与工具让前后端进行沟通契约的 Mock 服务Mock Server。用于模拟一个服务器为特定的接口返回特定的值。契约测试。对前后端协定的 API 进行测试。前后端胶水层。如 BFF Backends for Frontends根据客户端的需要对 API 进行聚合、适配、裁剪等。而使用这些工具的时候往往容易出现一些问题。消费者无法驱动的契约消费者驱动顾名思义就是在我们协定契约的时候按消费者的业务实现角度与生产者一起协定契约。在实践上往往由于后端在项目中的主导地位导致协商的结果不会按消费者需要而是按生者需要来生成契约。造成这种结果的因素有很多后端才是实现方。所以你常会听见『你行你上』笑~。从实施成本考虑。诸如于跨服务调用的成本等等后端的职级高——毕竟后端已经有了几十年历史了。为了更『美』的后端架构——导致了更『差的』前端架构。我的意思并不是说按生产者来主导有什么问题而是配不上『消费者驱动』这五个字。诸如于我们获取某个 API 的时候前端所需要的是相关的信息而不是对应的实体 ID。而后再由前端去获取对应实体的信息。从逻辑上来说由前端获取或者后端获取从技术上来说并没有多大的问题。但是从用户体验上来说并没有那么友好。后端间的 API 调用可以是几十 ms 级别的而前端多调用一个后端 API在网络上的传输时间往往都是几百 ms乃至几秒。生产者的契约测试所以让我们再看看各个团队所宣称的消费者驱动的契约测试。消费者驱动的契约测试Consumer-Driven Contracts简称CDC是指从消费者业务实现的角度出发驱动出契约再基于契约对提供者验证的一种测试方式。如果你不是消费者驱动的契约而是后端一口气定出来的接口你怎么能叫『消费者驱动的契约测试』按这样的做法它只能叫生产者的契约测试。既然是生产者的契约测试那么它就无法保证说API 修改不影响消费者使用——因为消费者压根就没有参与到契约的制定生产者可以按照自己的需要来修改契约。所以生产者到底是在给谁测试又是在测试什么东西契约测试的契约作为 Mock Server——不行在大部分的项目中对于契约的使用存在问题即模式错了。契约测试需要围绕业务流程施展而不应该相互隔离。如果契约的用例不丰富便无法串起整个系统的流程。而作为 API 的提供方应该保证业务逻辑是可以串联起来的。从用户的登录开始到用户获取数据展示列表页能进入详情页等等。我们做契约测试的目标是让代码修改不影响 API 输出。后端需求一改契约测试会挂后端知道出现问题会进行修复。如果前端用的是契约测试的契约提供的 Mock Server前端的测试也会挂这样问题就不会往后流。所以契约不应当给前端做本地开发和测试 。没有契约的 Mock Server——不行对于小团队来说去采用原始的 API 方式反而更加有效率对于大团队来说这样的方式并不可行。既然沟通那么麻烦那么我们就分开吧。如果契约和 Mock Server 是分开的那么维护前端 Mock Server 的人很很难识别到修改。相关的问题在测试不及时的情况下有可能在上线后才发现。也因此从理想情况来说这个 Mock Server 是契约动态生成的并能根据后端现有最新的契约更新。或者后端在实现契约测试时要做的是只测试部分数据而不是为了测试而测试。只有 DDD 的微服务——不行尽管 DDD 模型不一定非要与 API 绑定但是由于种种原因真正在实践的时候就不是这么一回事。我们可以看到在很多的项目里DDD 返回的实体资源最后可能与 API 的字段一致的。但是它并非是业务上想要返回的逻辑各个客户端PC Web、小程序、Android 端、iOS 端等还都需要进行二次的处理。这就是为什么DDD 微服务一定要配合一下 BFF 的原因。缺少前端、后端的 BFF——不行实施 BFF大家并没有啥问题。可一谁来维护这一层胶水层的时候大家都问题都来了——前后端都不愿意维护这个 BFF。对于前端来说开发者只是 API 的消费者突然间又变身成为生产者对于后端来说开发者原本不需要了解显示逻辑现在也要涉及到这部分的内容。不过呢我们可以保持一致的是后端是 API 的生产者。而如果生产者没有参与到 BFF 的开发那么就会引发另外一个问题API 发生变更的时候可能没有同步到 BFF——尽管每个项目都有自己的规范但是只要是由人来执行的都可能会出现问题。那么我们就需要一个 BFF 的契约测试那在第一时间知道 API 的变化。虽然感觉怪怪的但是我们还是将客户端的契约测试前移至了 BFF 层。所以消费者驱动的契约在哪里呢解决方案BFF大家都懂了。前端为主写 BFF前端写 BFF 并不是一件容易的事。你要懂微前端要懂主流的微服务框架如 Spring Cloud要懂 Java。与此同时还需要了解各个 API 的变化 情况。对于前后端分离团队而言要做样的工作太难了。而尽管你可以采用 Node.js TypeScript但是它也意味着你要成为一个 Node.js 专家。如果让我用 Node.js 写 BFF那我还是宁愿和以前的项目一样写 Scala 来作为 BFF。所以我并不推荐使用 Node.js 作为 BFF。一来没有阿里巴巴强大的 Node.js 专家群二来我对于成为 Node.js 没有兴趣。用擅长于某一领域的语言去做某一领域的事而非用擅长的语言去做每一领域的事——兴趣和爱好除外。GraphQL as BFF大家都懂了。前端防腐层参考《整洁前端架构》。消费者的契约测试我们在诸多项目实现了针对于生产者的契约测试。其中也包含了之前我写的 mest 框架它是通过结合 TypeScript 的 Interface 来验证后端接口是否一致。当你没有办法的时候这也是一个不那么差的做法。换个问题来思考的话就是以生产者来解决这些问题。直接转换模型为 Java Class 和 TypeScript 是一种更简单的做法。结论没有银弹。
