@fngtz09 外包就是这样的。人员流动性很高，肯定不会太注重质量。而且说实话，做外包并不是很赚钱，多数靠的是压榨人工。
所以专门的外包公司质量基本不用太期待。

@fngtz09 流程倒是无所谓，就算是兼职也可以找第三方公司签。
不过靠谱外包公司确实不好找，我倒是认识几个，不过也不知道靠谱不靠谱。。。

小于一个星期的自己写就可以了吧。。。
或者找个靠谱兼职就行。

双持啊，K30 至尊它不香吗？

@jiobanma GraphQL 的一个功能，你看一下 Demo 一般都有。

@jiobanma 嗯。你试的时候注意一下，不要光看例子那些从内存里直接返回数据的，试着把查询打到数据库里。如果你一次返回一个对象数组，然后数组里的对象还嵌套了查询，数据库没准直接就炸了。
Data Loader 就是用来解决这个问题的。
这俩试过了，GraphQL 做查询的坑基本就趟过去了。然后就是 Mutation，权限，Log 等等。。。

@optional 其实做聚合也是一样，简单查询还行，复杂一点的你就得写 DataLoader 。
其实做接口这个事，不管你是 Restful 也好，GraphQL 也好，瞎怼也好，都只是个形式和工具。该做的事一件也不会少。
各有优缺点而已。也不是说上了 GraphQL 就万能了，只是说如果聚合和标准化是你的痛点的话，那 GraphQL 可以帮你尽量避开这些坑，但其他的坑该有也还是会有的。

@jiobanma 是的。我说的你不能在 Rest Controller 里面干这个事主要是因为这是违背 Restful 的设计原则的。单独做一个 GraphQL 用的 Controller 就可以了。
你可以去看一下它的 HelloGraphql 的 Schema 和 Type 是怎么写的，那个是核心。

@jiobanma 你这个做法是不行的。你没法从一个 Rest Controller 里面直接调用 GraphQL 。GraphQL 也不是拿来做数据聚合用的。
它的核心就是你说的那个 JSON 语法，通过 POST 请求过来的 JSON 被解析后，GraphQL 会去调用对应的 Query，然后你这些手写的 Query 会调用和聚合相关的 Type 。
这一个链条里的 Query 和 Graph Type 都是你自己手写的，和 Rest API 用的类型是不一样的。比如按你的例子来说，你在 User 里面挂个 Group 。一般的 Rest API 只会从 User 里面返回一个 Group ID 。但你如果做成 GraphQL 接口的话，你需要自己写把这个 Group ID 转换成 Group 对象的查询。
GraphQL 会帮你在需要的时候去调用这个查询而已。

这种需求 GraphQL 可以直接解决。你定义 GraphQL 对象的时候直接用 User 里面嵌套一个 Group，前端需要从 User 里面获取所属 Group 的时候直接拿这个对象就可以了，GraphQL 会给它填进去。
当然很多时候你需要自己写 DataLoader 。
你如果不能用纯 Rest API 完成接口设计，那么多数是前端需要依靠后端来聚合数据。大概率是因为性能原因没办法在前端做聚合。GraphQL 本身可以帮你做一些简单的聚合，同时也可以直接减少请求次数。但是最终你很可能还是要自己写一些 DataLoader 或者构造一些用来做 VM 的 Graph Type 。
对于后端来说，用 GraphQL 不会带来太多便利，该写的还是要写。只是前端可以一定程度上自行决定返回的数据结构，你也省了很多沟通成本，提升的是整个项目的效率。

@jones2000 产品的编译机是不会中毒的，这个测试应该主要还是针对开发机的。

趋势。。。不是被亚信买了么，还算外企？
话说你们这杀软是真的难用，用过这么多杀毒软件里，生理反感度仅次于 360 。

第一次见 SSD 这么坏的。
不过一般也就当系统盘和游戏盘用，重要文件都放 NAS 里了。

Everything 快是因为用了 USN，不是所有硬盘都能用的。
你总不能说操作系统带的搜索连自己支持的硬盘格式都用不了。
所以除非建立索引，剩下都是靠遍历文件。最简单保险。

GraphQL 一把梭
梭完了发现你得写一堆 Loader

正常不就都这样吗？同一个编程范式下的语言大多都很类似，做简单项目只要熟悉一下语法就好了。
剩下的多数都是语言无关的东西了。
除了 C 艹