回答一下GraphQL为什么没有火起来?

前言

好的技术应用于实际业务必定不是全盘照搬，应根据实际须要借鉴先进经验优化自身不足，就像没有一个企业能永远生存下去。软件系统也同样，活下去，保持将来碰见性，符合公司组织架构和发展水平是最重要的。graphQL在国内目前没有火起来，是时机还没到来。

要想理解graphQL就要先放弃经验主义，它根本就不是用来解决现有框架所解决的问题的。

如今什么最火？

微服务MicroService、serverless、微前端MicroFrontend。

关系链: DB - > MicroServices微服务 - > Microfrontend微前端

后端解耦，前端聚合；体如今前端的聚合就是微服务化架构。

为何说graphQL要扯这么多虚无缥缈的技术？

窃觉得一种技术是绝对不会单独存在的，全部前沿的技术都是相关联的。graphQL能火起来正是这些技术发展所催生的一个前端领域工具。围绕着graphQL的各类语言的框架层出不穷，graphQL一样承载着技术时代转型布道和实践做用。了解这些后能够坚决的去研究graphQL，不至于被后生challenge。

一件事物变得简单必定是靠一些事物变得复杂来支撑的，如同社会发展同样，商品经济的高度发达，使得高品质生活愈来愈容易实现。过去云概念火的时候不少公司都在作云，可真正活下来的就那么几家。 先不谈商业模式对不对，单讲人才缺口就不可能支撑那么多公司能作出真正的云服务。但过去10年BAT就像互联网界的黄埔军校同样培养不少具有独立技术创业能力的人才, 这是国内任什么时候代所不具有的人才环境。因而靠技术创业的公司会发展一大波，像severless这种技术模式类型的公司必定会发展起来的，到那时graphQL可能会火起来，也有可能会有新的轮子来与之抗衡。

-----------一本正经的分割线-------------

主流Microservice与Serverless有哪些产品？

主流的Microservices产品

• Google Kubenetes
• Microsoft Azure Service Fabric

主流的Serverless产品

• Amazon AWS Lambda
• Microsoft Azure Function
• 小程序serverless
• Fission是一个Serverless开源框架

Microservice与Serverless的优劣势比较

	Microservice	serverless
优势	适合构建复杂的应用程序。它将复杂的应用分解为独立的服务，被分解出来的多个可管理的服务能够经过约定的接口相互通讯，每一个服务能够做为个体独自修改、扩展和管理，而单体软件很难维护或修改。	1.开发者只须要专一于业务逻辑就能够了，开发效率更高。 2.开发者只须要专一于业务逻辑就能够了，开发效率更高。 3.按需付费， 成本相对比较低。
缺点	仅适合复杂项目使用，须要较高的架构能力，须要系统性团队支撑。 我以为这不算缺点，就像在说航母费油是缺点同样	1.适合处理复杂的业务逻辑，它更适合调用云上的其余服务，粘合关键的产品。 2.排查问题困难，由于逻辑散落在各处。 3.Serverless没法用于高并发应用，为每一个请求启动一个进程开销过高，流量瞬间爆发容易致使超时。 4.Serverless调用之间不能共享状态让编写复杂程序变得极度困难。 5.业务拆分问题 厂商锁定 对已存在的项目迁移困难

给前端带来了什么？

serverless理论是前端创造的，这个里有一篇文章论述的很是好 精读《Serverless 给前端带来了什么》

• 会改变先后端接口定义规范。
• 必定会改变先后端联调方式，让前端参与服务器逻辑开发，甚至 Node Java 混部。
• 大大下降 Nodejs 服务器维护门槛，只要会写 JS 代码就能够维护 Node 服务，而无需学习 DevOps 相关知识。
• 对一个自由开发者：将来服务器部署更弹性，更省钱。部署速度更快，更不易出错。

前端工程师会面临哪些挑战？

首先，一个生态的繁荣对于从业人员来说是很好的事情，就像react、vue的发展并无让用jquery框架写项目的FE丢掉工做同样，反而由于前端能作的愈来愈多前端发展的也愈来愈好，不少项目前端抢了app端和后端同窗的饭碗。

这个问题我没有想好！学习一门语言或专一一个领域应考虑是否能给本身带来长期发展，选择能够从所创造内容的服务周期、优点特性考虑， 如C++永远不会过期，但也比不上流量明星语言。 语言学习上最好能掌握最有实力的语言和最火的语言。

什么是微前端？

2016年由ThoughtWorks提出微前端的概念，微前端是一种相似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还能够独立运行、独立开发、独立部署。

关键词： 主从式设计 , 微前端的主从设计是区别于其余前端技术的特色，主从设计的前提是这一坨业务模块必须关联才有其必要性。 强行设计可能就会像【调度中心】同样产生不良的结果。

有哪些表明的产品？

• AdWords 广告服务,google最大的微前端项目，其中有数十个团队的100名开发人员使用相同的“产品”，但他们有本身的发布周期。
• EmberJS, LinkedIn全站已经ember化, 优秀的文档体验是ember的优点
• single-spa, 目前有4k star，亮点是抹平各类框架技术栈、模块加载。 link
• Mooa, ThoughtWorks黄峰达, Mooa 是一个为 Angular 服务的微前端框架，它是一个基于 single-spa，针对 IE 10 及 IFRAME 优化的微前端解决方案。Mooa 框架与 Single-SPA 不同的是，Mooa 采用的是 Master-Slave 架构，即主-从式设计

一些实践

美团微前端实践，有点...link

single-spa实践 抹平各类框架技术栈，在一个微服务入口加载模块，这个想法很大胆，除了开发阶段看起来像是合家欢，同时也把全部问题集中在了一个桶里，不知道会出现什么难以收拾场面。link

为何是graphQL?

能够以上面提到的任意技术 + graphQL做为关键词来搜索一下，结果是graphQL和这些技术有太多的实践经验了。 彷佛成了前端通向将来后端的一道法门。GraphQL为几乎全部主流语言都编写一个GraphQL服务端框架，这可不是通常的开源了，这是在作标准了。一流的事物才是作标准。

对于前端来说之后获取任何数据（业务接口、服务接口、其余类型接口）均可以统一的使用GraphQL，这不就是 【一站式服务大厅】 吗？

GraphQL是什么？

• GraphQL是Facebook定义的描述与业务相关的数据模型的语言规范，并提供了多种编程语言的实现。看名字是指望可以比肩数据库领域的SQL，成为服务调用领域的标准。
• GraphQL位于服务的调用者与服务的提供者之间，提供给调用者统一的、与业务逻辑相关的服务查询语言。
• 研究下Vue Cli就会发现服务和GUI之间的通讯是经过graphQL实现的，有趣吧。

为何不是RestAPI？

GraphQL 到底是一个炒做流行语仍是真正会带来一场变革？有趣的是，我以前列出的大多数从 GraphQL 获益的公司都有如下这些共同点。

• 他们拥有包括移动端在内的多个客户端；
• 他们正在转向或者已经采用了微服务架构；
• 他们的遗留 REST API 数量暴增，变得十分复杂；
• 他们但愿消除客户端团队对 API 团队的依赖；
• 他们注重良好的 API 文档和开发者体验。

RestAPI 不是被抛弃， GraphQL只是将不适合RESTAPI作的事情承包了，而且还抢了风头，graphQL并不能彻底替代RESTAPI，GraphQL只是整合过程当中引入的一层而已。就像那些拿季度奖的员工同样，你想只用这些人干活是不现实的。

link

结论

GraphQL火起来的那一天才是前端美好时代的到来。期待...

see also

关于severless领域研究的比较深的人 phodal, blog，csdn