null 和 "" 本来就不是一个含义，在很多语言都不一样的，只是 js，php 等动态语言会自动转换而已。
GraphQL 很严谨的，业务上也应该区分开来，resolver 里校验 "" 是可以的。

业务真要改了，不都是改业务逻辑代码？所谓的被依赖和复用大部分都是拍脑袋凭空想象，就自己写的那一个接口依赖了而已，既然都是自己写的，不写冗余的类和接口，代码更少不是更容易改？

controller -> manager -> service -> dao -> mapper
manager, service, dao 大部分都是重复的代码，一个方法，里面就一行，调用下一层的同名方法，业务都是 SQL 实现，
一堆功能几乎重复文件看着就头疼，调代码跳来跳去也烦

每个业务写一个 Service 和 ServiceImpl，即便操作同一张表，别人也不会复用你的，甚至自己在其它业务也不会复用。
方便单元测试？有几个项目真正把单元测试落实的？需求总在变，测试代码经常跑不通也得一起改，加班加点业务需求都忙不完还有时间管单元测试？
敏捷开发原则之一：简单的方法就是好的方法
过早优化是万恶之源，不要在不确定的情况下加入不必要的复杂性

怎么统计的下载量呢？

@cool007zqw 为什么你能发图片？？


GraphQL 的，和 React 很像
https://graphql.org/img/logo.svg

Go 没有 null，但有 nil 啊

关键词 ORM，嗯，某爬虫可能要来了 /狗头

具体的协议可以发出来看看，帖子的描述看起来只是类似 ZUUL, ZooKeeper 那种加上类型描述，但并没有看到前端定制接口返回的字段，还有组合数据等功能

前端能自由组合数据吗？

看了下 OData 官网文档，协议挺复杂的，没有 GraphQL 的 Schema 直观

@dcoder 你看，我同样也能在知乎上找到支持 GraphQL 的回答：
"有人吐槽性能，只想说如果一定要做接口数据聚合这件事的话，GraphQL 遇到的问题几乎都会遇到，而并不是没有方案在解决此类问题。就接口数据聚合这事来说，它目前可能是最优方案。而就接口数据聚合这事需要不需要，个人认为微服务架构下几乎是必须。
还有提到 join 的，会有这个问题，但在微服务架构下，各自分管自己数据库这种场景下不也是一样么，抛弃了一些数据库本身所带来的直接好处以做妥协。如果本来服务粒度划分就很细，不用 GraphQL 同样也会遇到这个问题。"

"总而言之，个人的观点是：一个产品需要整个数据模型架构图之类的东西帮助所有开发人员理解来减少沟通和其他软成本。微服务架构下本就需要不同服务的数据聚合后透出给前端，GraphQL 可能是目前最好的数据聚合方案。后端在标准化的流程下，可以把方向往自动化生成大多数代码上去走，然后在此基础上去做定制化修正和优化，最终其实能极大增加开发效率，也能让不同的开发人员开发出规范雷同的代码，利于以后的维护。"

GraphQL 了解一下，FB 出品，大幅提高前后端的接口联调的效率
www.v2ex.com/t/589138

@StarkWhite 没必要像评论里一堆人抓着它的缺点不放，非得拿去干不适合的事情，然后说它垃圾

@Mithril 赞，适用范围内使用就好了

@dcoder 知乎那个帖子都是 16 年前的了，现在都 9102 年了，性能问题也有 dataloader 来解决了