前言
好的技术应用于实际业务一定不是全盘照搬，应根据实际需要借鉴先进经验优化自身不足，就像没有一个企业能永远生存下去。软件系统也一样，活下去，保持未来遇见性，符合公司组织架构和发展水平是最重要的。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只是整合过程中引入的一层而已。就像那些拿季度奖的员工一样，你想只用这些人干活是不现实的。
结论
GraphQL火起来的那一天才是前端美好时代的到来。期待...
