從前端到全棧

1、 從前端技術演進看前端發展野心

前端的技術近幾年發展很是迅速，各類框架也如同雨後春筍。

從兩個維度去分析前端的技術發展，一個維度是前端複雜度，具體來說就是前端在解決建立應用複雜度方面作的一些事情；另外一個是從廣度層面看前端作的事情， 這兩個維度構成了一個相似於二維平面的時間事件平面。

1. 逐漸下降建立應用複雜度

單看複雜度，前端最開始的階段只有HTML、JS、CSS，應用雖然是很是簡單的，開發起來倒是很是複雜的，所以，單單只是DOM操做方面就有大量的DOM操做API。爲了下降操做成本，就出現了DOM操做框架，好比jquery。這個階段相似於從原始的刀耕火種進入石器時代。對dom的操做帶來了很大的便利性。儘管如此，真正在構建一個複雜應用的時候，由於業務邏輯和手動操做dom邏輯交織在一塊兒，應用維護變得愈來愈難。

下一個階段，引入了MVC分層思想，好比backbone,這可以將邏輯梳理的更加清晰一些。不過，MVC仍是須要去關注視圖層的。

接着，就出現了mvvm框架，開發者不須要再關注視圖層的更新，只須要關注邏輯層、數據層。這一點爲構建複雜大型app提供了極大的便利性。mvvm從Angular到如今react、vue的普遍應用，前端在邏輯構建層面發展已經到了一個新的階段。

在構建大型應用的時候，僅有邏輯層是不行的，還缺少工程性的思想。所以，出現了打包的模式，幫助咱們構建更復雜的應用。這樣咱們所能作的APP複雜度是一個指數型的增加。

爲了進一步提升可構建應用的複雜度、加強前端的性能，assembly技術標準出現，提供了前端字節碼的標準，爲建立更加複雜的應用打好了堅實的基礎。

2. 一直在擴展的前端廣度

剛開始只能在瀏覽器上運行，後來有了node代碼，可讓咱們的代碼擴展到服務器端。緊接着PC端有electron。再到移動端有RN框架，支持咱們向移動端進展。

如今出現了小程序，小程序框架可以讓前端繼續在移動端輕應用作探索。

這裏沒有講到的嵌入式開發，這方面也有相應的解決方案。

前端不斷擴展廣度，把前面的邊界不斷擴大。

最終前端想一統天下，把前端全棧化。

2、 同時知足技術需求和商業需求的前端全棧

全部的技術在發展時期都有兩條線去支撐着它發展，一條線是技術需求，即技術層面的技術創意和技術訴求；另一條線是商業需求，即技術要知足對應的商業訴求。

一個解決方案只有同時知足商業訴求和技術需求，才能蓬勃的發展。若是偏離這兩條線，就很難發展起來。舉個例子，好比Symbian，有些人有想嘗試這個技術訴求，可是由於它已經脫離商業需求的層面，因此這個技術會慢慢被淘汰掉。

那麼，若是僅有商業需求又會出現怎樣的狀況呢？

好比，2000年的時候對AI有商業上的需求，可是技術需求並知足，當時AI就是一個要被擱置的東西。

前端全棧，是怎樣在知足技術需求的同時知足商業需求的呢？

咱們迴歸到移動端APP的開發實際場景，只有兩個層面：一個是UI交互界面的開發，這個是能夠被用戶感知到的，另一個是用戶感覺不到的服務邏輯層面。若是來看現有的開發模式，單單從UI交互界面上來看，就有不一樣的平臺端android、ios、h5，對應的語言有Java、OC、swift、js等幾種語言，後端的語言和技術實現是更多的。在如今的模式下，一個小型公司若是須要開發一個完整的APP項目，就須要六種技術！

每一種技術若是須要找一個專門的人來作，這就須要6我的。那麼反映到公司企業運營上面，人力成本是比較高的，除了人力成本還有一樣很是高的溝通成本。從溝通的角度上來看，全棧式開發模式的出現，可以讓一我的負責更多的業務開發，下降溝通成本。

因而可知，前端全棧既知足技術需求，也知足商業需求的，因此我相信將來前端全棧必定會蓬勃發展。

3、 打破物理隔離，實現真全棧

再回過頭看前端散落的各類技術，在這個發展的過程當中，有一個很深的隔離，這個隔離本質上就是物理隔離，好比前端和後端，存在手機和服務器之間的物理隔離。

**由於各類端是實體端，每一個端之間都存在物理隔離。**就好比前端和後端，存在手機和服務器之間的物理隔離。若是能解決這些隔離，就能夠把前端的技術作到真正的統一開發模式，才能作到真全棧開發。

其實後端的物理隔離，好比每臺服務器之間的物理隔離，能夠經過雲端化，咱們把代碼上傳到雲端平臺，雲端平臺會屏蔽機器之間的物理隔離，暴露給開發者的只有一個集羣的概念，而不是一臺機器一臺機器管理部署。雲端化以後，後端的物理隔離被消除了。

咱們如今的前端代碼和服務器之間終存在一個物理隔離，目前的解決方案是經過中間的協議打破物理隔離，好比http協議，但http協議畢竟是中間協議。

而serverless的理念就能完徹底全解決掉這層物理隔離，由於代碼即服務，serverless能打破這層隔離實現前端的真全棧。

Serverless中的FaaS，函數即服務，我在使用後端服務的時候，再也不關心後端的ip地址，後端的域名是什麼樣的，直接調用函數便可，對前端來講，後端服務是一個函數，函數就是前端的代碼的一部分，後端服務和前端徹底的融合在一種代碼體系裏去了，這樣後端的服務便是一個函數，至於這個函數是在前端實現，或者是在後端很遠的地方實現，開發者均可以不用關心。因此說，severless打破了物理隔離。開發者再也不去作任何隔離中間層的事前，我只須要關心函數的實現就能夠了，函數也是用個人前端代碼來寫，因此達到了充分融合的定義。

回過來看具體的實現場景，好比雲開發，整個小程序的先後端邏輯都能在一個IDE裏面完成，用戶其實徹底不用擔憂哪些是服務器的邏輯，他們都去向了哪裏，只須要像前端函數同樣去理解就能夠了。雲函數如今也支持了本地調試，就像前端代碼同樣調試，因此能夠作真正的前端全棧技術開發，這對現有的開發模式是一個很大的革新。

4、 小程序雲服務的發展優化

那麼，在大前端技術發展的這波浪潮裏面，小程序雲服務又有什麼樣的發展呢？

早在2017年初小程序正式發佈的時候，第一代騰訊雲小程序雲服務就已經誕生了，但隨着8月份全面向我的開發者開放，咱們發現這套支服務仍是有必定門檻的。因而就開始着手去作更深度的雲服務整合和優化，纔有了後來的wafer2 和如今的雲開發。

早期第一代產品 Wafer 的整個開發部署流程，統計了一下大概須要十幾步，對許多中長尾的客戶來講並非那麼友好。因而咱們開始着手優化。

**經過整個優化，能夠簡略成四步。**第一步是經過一鍵的配置購買就能把雲開發產品開通起來，第二步是工程師進行小程序的先後臺開發，第三步進行代碼的預覽上傳，測試體驗完，最後即是發佈。通過咱們這一兩年的努力，小程序開發的流程已經由十幾步簡化到四步了。目前若是從市面上來看，咱們這個產品在用戶體驗以及流程簡化度上，在行業內是較爲領先的。

那麼，咱們騰訊雲團隊和微信團隊如何一步一步優化咱們的產品，將產品的接入門檻下降、流程變簡的呢？

最初咱們看到的是能夠將 devops 的部份環節給優化一下，包括代碼上傳部署。這就催生了後來的Wafer 2，亦即第二代的小程序雲服務產品。

另外開通購買步驟也是比較繁瑣的。將騰訊雲和小程序的帳號打通後，能夠作到一鍵受權而且開通環境與服務，而且咱們提供了一個免費的開發環境，這樣可讓更多開發者在進來發布小程序以前，能夠以更低的成本門檻用上雲開發。

剩下還能夠優化的就只有 SDK 引入和填寫配置的環節了。

SDK 其實能夠採用內置的方式，畢竟小程序的前端接口也是直接內置到運行環境的 webview裏面的。可是配置這塊並不太好作了。由於一直以來，小程序前端和後臺的開發都是割裂的，所以整個用戶的鑑權機制都是交由小程序開發者本身去處理。但爲何小程序與雲服務必定是要割裂的呢，爲何不能整合到一塊兒呢？而 Serverless 這種開發模式是先後端緊密結合的最佳粘合劑。

通常而言，請求從小程序側發起，到雲服務的後臺邏輯進行鑑權處理，若是鑑權成功再調用微信公開發 API，而後再把數據返回到小程序。

但咱們稍微將整個請求鏈路改變一下，小程序側的請求先經過微信的服務，認證並鑑權成功以後，再到騰訊雲這邊的 Serverless 服務進行邏輯的處理，處理完畢後再返回到小程序側。這樣，咱們把整個配置和鑑權服務都幫用戶完成了，這又大大減輕了開發者的負擔。

經過介紹整個小程序雲服務的優化歷程，相信你們能感悟到整個產品的理念，就是但願一方面雲能力逐步成爲小程序開發的基礎能力，另外一方面也但願儘可能減小開發者須要理解的概念。

5、 從前端開發到全棧開發

在雲開發模式的推進下，咱們開發模式是怎麼一步步走到如今的開發模式的？

在Web剛出現的時候，後臺開發本就是大包大攬，後臺邏輯完成後，再把模板和數據吐出來到瀏覽器渲染。當時基本上都是作一些比較簡單的Web應用。可是當時沒有人會吐槽你的後臺工程師只有一我的，怎麼都把後臺和前端服務都幹完了，可能當時的業務邏輯並非很複雜，前端技術也不是那麼的規範化，應用場景不是那麼多，因此纔出現這樣的狀況。

但是到後來，隨着瀏覽器逐步發展，JS、CSS、HTML有一個規範委員會幫它每一年制定一些新的特性。並且隨着業務場景愈來愈複雜，這種狀況下開始提出先後端分離，開始要求後臺和前端是分開兩我的作事情，先後兩端是經過API的請求和返回去作一個數據交互。

再到了2008年的時候，喬老爺子憑一己之力開啓了移動端的開發生態。到了2017年張小龍大神也跟微信團隊推出了小程序且打造了小程序生態。這個時候不少專家提出了「大前端」的概念，但願只寫一份代碼，就是編譯並完成不一樣客戶端的業務，這些端只須要共享一個後臺服務就能夠了。

這個時代國外出現了一些跨端方案，好比React Native，國內也涌現了 Taro， Omi 等優秀的跨端方案。這幾個時期的前端職能是有明顯擴張的。

只作了大前端徹底知足不了前端的野心，隨着Node.js的發展，有一些中臺的服務，好比同構渲染和業務接口但逐步轉給Node.js 來作。後臺的同事開始專一於去寫一些後臺的調度服務或者優化整個數據的讀取性能。這個時期，前端開發者也開始從前端逐步日後臺作一個拓展。

但大前端的步伐遠遠不僅於此，在不少業務場景裏面，前端工程師比較貼近客戶，因此他更可以去理解到一些業務邏輯，不管是業務的前臺或是後臺，交給前端工程師來作是更好的。舉個例子，雲開發的其中一個客戶是惟品會的前端團隊。他們其中有個業務須要依靠後臺來支持，但他們的後臺人力很緊缺沒有辦法立刻投入支持。因而他們的前端就藉助雲開發，投入1個前端工程師就迅速把這個業務給作完上線了。其實許多公司的業務都有相似的狀況，公司業務發展很是快，但有的時候要前端等待後臺的人力，這樣就影響到整個公司的業務發展。

但是前端的全棧開發的模式，從前端到後臺，把全部的業務全都寫完了，其實你會發現又回到咱們最初的一個工程師大包大攬的作事情。但是這個業務是複雜的，若是沒有一個工具或者一個雲的基建設施去支撐這個夢想的話，實際上是徹底不能實現的。

面對這樣的挑戰，咱們應該怎麼答覆咱們的老闆呢？

騰訊雲目前提供的解決方案就是雲開發。

傳統開發模式會讓前端變成大包大攬地作業務，實際上是至關困難的，由於一方面要開發前端和後端的邏輯，還要處理全部的運維的事情，靠一我的是不可能的，因此纔有瞭如今這樣的傳統分工模式，就是前端、後臺、運維。若是把這個業務用上雲開發的話，咱們主要關心的只有一小部分，主要都是咱們的業務邏輯。至少只要這個工程師可以懂Node.js，基本上就能夠把服務穩定、性能卓越和有必定安全性的小程序應用獨立開發出來。

雲開發的開發模式真正能夠實現前端工程師全棧開發的理想模式。