回答一下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