做前端的这个避不开的，是趋势。

JAVA-Script 惊了。

建议单独开个账号做。

如果不是密集运算型不可能差这么多的，听你的描述仅仅是从 mongodb 获取数据的，别说 10 倍了，我觉得差两倍都不正常。不如把代码贴出来看看。

@fe619742721 要~

可乐也有效，个人感觉明显

剧情太生硬，别的还行

@kajweb webpack 其实没什么硬性要求，遇到问题能找文档来解决就行，更多的是考察个人综合素质和技术基础素养，而不是会什么。

@momo12 阔以的

@Asyncway 入职时间倒是可以等，只不过名额不是无限，可能招到合适就关闭了。

用自己的微信打开一下然后把 Cookie 复制出来，爬的时候改一下 UA 设置上 Cookie 就可以了

GraphQL 能够帮助解决一部分非描述性接口的性能问题，说不能的只是不知道 GraphQL 请求方描述的内容有什么用、怎么用而已。

@zjsxwc 这种是简单业务，几乎没有额外消耗的，多一个字段少一个字段并没什么差别。但是稍微复杂点的业务都不是一个查询就能查出来的，这时候前端描述的协议就显得很有价值了。

@abcbuzhiming 那要看你怎么定义能力了，没有 graphQL 的协议支持，后端能知道前端需要哪些字段么？

@zjsxwc GraphQL 极其有价值的一点就是前端没有请求的属性可以不消耗资源去生成，到你这就变成“服务器查询执行业务的消耗仍旧不变”了？你确定你用过么

开喷麻烦先搞清楚一点行么？
GraphQL 生产环境用了 2 年了，适合新项目，不适合老顽固后端。
有一定的门槛，水品差的没有按照 GraphQL 的逻辑来思考反而会增加工作量，还不如不用。
摸透了之后是真的爽，接口效率大幅提审，版本迭代快得飞起。

没毛病确实应该后端做，数据量不大后端可以翻转一下把 name 的值变成 key 这样速度比较快，如果很大可以借助其他工具做索引来搜索。

整个项目查找替换一下，catch 里面执行上报的方法，也就 1 分钟的事儿。

服务端用 PHP 和 Node.js 都有同一个问题，不同水平的人写出来的东西相差太多。不像 JAVA 这种强类型语言容易形成团队规范，更容易协作。
如果团队水平够的话，PHP、Node.js 都可以写出漂亮易于维护并高效的工程。