那我们来分析一下,当前端需求变化,涉及到改动旧需求时,会有以下这些情况:做加法:产品需求增加,页面需要增加功能,数据也就相应的要增加显示,那么REST接口也需要做增加,这种无可厚非。做减法:产品需求减少,页面需要减少功能,或者减少某些信息显示,那么数据就要做减法。一种通常懒惰的做法是,前端不与后端沟通,仅在前端对数据选择性显示。因为后端接口能够满足数据需要,仅仅是在做显示的时候对数据进行了选择性显示,但接口的数据是存在冗余的,这种情况一个是存在数据泄露风险,另外就是数据量过大时造成网络流量过大,页面加载缓慢,用户流量费白白消耗,用户体验就会下降。另外一种做法就是告知后端,要么开发新的接口,要么,修改旧接口,删掉冗余字段。但一般来说,开发新接口往往是后端开发人员会选择的方案,因为这个方案对现有系统的影响最低,不会有额外的风险。修改旧接口删除冗余数据的方案往往开发人员不会选择,这是为什么呢?这就涉及到了系统的稳定性问题了,旧接口往往不止是一个地方在用,很有可能很多页面、设置不同客户端、不同服务都调用了这个接口获取数据,不做详细的调查,是不可能知道到底旧接口被调用了多少次,一旦改动旧接口,涉及范围可能非常大,往往会引起其他地方出现崩溃。改动旧接口成本太高,所以往往不会被采取。同时做加减法:既有加法,又有减法,其实这种就跟新需求没啥区别,前端需要重做页面,后端需要新写接口满足前端需要,但是旧接口还是不能轻举妄动(除非确定只有这一处调用才可以删除)。往往这个时候,其实用到的数据大多都是来自于同一个DO或者DTO,不过是在REST接口组装数据时,用不同的VO来封装不同字段,或者,使用同样的VO,组装数据时做删减。看到这些问题是不是觉得令人头大?所以需求频繁改动是万恶之源,当产品小哥哥改动需求时,程序员小哥哥可能正提着铁锹赶来...... 那么有没有一种方案或者框架,可以使得在用到同一个领域模型(DO或者DTO)的数据时,前端对于这个模型的数据字段需求的改动,后端可以根据前端的改动和需要,自动适配,自动组装需要的字段,返回给前端呢?如果能这样做的话,那么后端程序猿小哥可能要开心死了,前端妹子也不用那么苦口婆心地劝说后端小哥哥了。 所以GraphQL隆重出世了!那么问题来了!Part 1 What is GraphQL
使用GraphQL接口设计获取数据需要三步: GraphQL获取数据三步骤1、首先要设计数据模型,用来描述数据对象,它的作用可以看做是VO,用于告知GraphQL如何来描述定义的数据,为下一步查询返回做准备;2、前端使用模式查询语言(Schema)来描述需要请求的数据对象类型和具体需要的字段(称之为声明式数据获取);3、后端GraphQL通过前端传过来的请求,根据需要,自动组装数据字段,返回给前端。GraphQL的这种思考模式是不是完美解决了之前遇到的问题呢?先总结它的好处:在它的设计思想中,GraphQL 以图的形式将整个 Web 服务中的资源展示出来,客户端可以按照其需求自行调用,类似添加字段的需求其实就不再需要后端多次修改了。创建GraphQL服务器的最终目标是:允许查询通过图和节点的形式去获取数据。