大家好，我是楊成功。
這是我的 2022 年第一篇文章。一直在想寫些什麼比較好，既然是新年，新年新氣象，寫點技術展望的想法是不是更合適？於是這篇文章的標題，也就是本文的核心思想出來了：
Serverless 背景下，一部分“前端工程師”會轉變為“應用交付工程師”
這裡有三個名詞：
- Serverless
- 前端工程師
- 應用交付工程師
下面就從這三個方面，聊一下我對 2022 前端的展望。
Serverless
什麼是 Serverless？
單從意思理解，非常明顯，就是很少的服務。
我覺得這個理解就很好。因為現在大家對 Serverless 的翻譯是 無服務，真正無服務嗎？也不是，我們先來看一下它的具體概念：
【Red Hat】Serverless 是一種雲原生開發模型，可使開發人員專注構建和執行應用，而無需管理伺服器。
聽不懂？大白話翻譯一下。就是說以前的服務啊，比如說我們前端要對接的介面應用，它們是要部署在 伺服器上 的。後端同學要開發一套介面，首先得申請一臺伺服器，然後將應用部署到這個伺服器上，用域名解析一下，才能給到前端介面 URL 地址，供前端呼叫。
但是 Serverless 出現以後，即便沒有伺服器，不懂運維，線上上部署應用也成為了可能。
關鍵點就在：沒有伺服器，也能部署應用。
那怎麼部署呢？先看一下 Serverless 的兩種形式：
BaaS：全稱 Backend as a Service，譯為後端即服務。FaaS：全稱 Function as a Service，譯為函式即服務。
BaaS 是指一個服務端應用，也叫雲應用。舉個例子，我們常用的阿里雲的雲資料庫，物件儲存，都屬於 BaaS。事實上不管是資料庫還是靜態資源儲存，我們完全可以自己在伺服器上搭建。但是因為有了像 雲資料庫 這類的產品，我們可以繞過伺服器，直接使用一個雲端的資料庫。
這就是 “無服務” 的第一層概念：淡化伺服器，直接接觸服務端應用。
注意：這裡是淡化伺服器，並不是真正的沒有伺服器。只不過是雲廠商已經將伺服器進行了抽象封裝，暴露給開發人員的直接是應用，因此對開發人員來說好像是無服務。
BaaS 最廣泛的應用在後端，因為後端好多基礎設施（如資料庫，日誌等）不用手動搭建了，有云廠商標準穩定的支援，可以把精力集中到業務邏輯上。
但是隨著前端的快速發展，以及後端的雲原生化，有些奇思妙想的大佬就這麼想了：“前端呼叫後端介面，都是在前端的一個函式中發起請求，這樣的話就必然需要後端提供一個介面服務。那我們是不是可以這樣，直接將這個函式部署在雲上，變成雲函式，供前端直接用，是不是就不需要後端的介面了？”
大佬一拍大腿，這想法竟然如此絕妙。這麼幹的話，前端豈不是要翻身農奴把歌唱？於是大佬們將 server 繼續 less，於是 FaaS 就出現了。
FaaS 是一種面向函式的構建和部署軟體的方式，也就是雲函式。FaaS 是對 BaaS 的又一次升級，在淡化伺服器的基礎上，又淡化了應用，直接向前端暴露函式。以前我們前端的函式都是本地宣告，本地呼叫。現在雲函式是單獨部署在雲上，供我們前端遠端呼叫。
這是 “無服務” 的第二層概念：淡化伺服器，淡化應用，直接接觸函式
事實上，Serverless 在發展到 FaaS 階段，才真正對前端產生了變革式的影響。
前端工程師
什麼是前端工程師？
早年的前端工程師更像是“頁面工程師”，絕大部分人的工作就是用“三駕馬車”將設計圖做成一張網頁，直到現在還有很多後端開發對前端的印象就是如此。
但是近幾年大家發現，前端工程師彷彿一直在“外卷”，不斷的擴充邊界。雖然還是頂著“前端工程師”的帽子，但是乾的事情早已經超出了傳統前端範疇。
從”擴充邊界“這個事情來說，大致分兩個方向：
向前：往產品和設計靠向後：往後端和運維靠
向前表現為，一部分前端開始對自己做的東西，會更多的思考“為什麼”？
以前是產品確定到設計出圖，前端只需要還原設計圖就好了。理想如此，但實際情況是有些地方產品和設計考慮不到，等落實到前端這才發現不可行，於是呢就只能“改需求”或“推倒重來”，這是前端最反感的事情。
這種情況一多，就會倒逼前端們不得不思考：這個頁面設計合不合理？互動方面有沒有問題？ 如果有問題，那這個需求我們就不接，產品先回去捋清楚了再說。這樣大大減少了前端的無用功，提升了開發效率，也漸漸培養了前端的產品思維。
除了產品思維，前端也在思考，如何在設計層面讓“圖”變成“程式碼”更容易。於是近年來出現了很多設計圖轉程式碼的方案，比如藍湖，還有阿里的 imgcook。這些實踐方案讓一個應用從設計之初，就有了前端的影子。
而向後發展的表現，典型是 Node.js 出現以後，以 Express 為代表的超輕量框架，因為相對簡單又是 JS 語言，因此在前端圈掀起了一股 “全棧開發” 的熱潮。這不是沒有原因的，有些小應用就是適合用 Node.js 寫，速度快效率高用過都說好。
但是在一些大型生產應用上，前端就夠不著了。特別是雲原生出現以後，後端的門檻蹭蹭的上來了。我相信有很多優秀的前端工程師，用 Node.js 接個資料庫，寫一些業務邏輯的介面，完全沒有問題。但是如果讓你搞一些後端的高階玩法，做一些伺服器運維的事情，你可能就整不來了。
哪些算高階？之前在網上看到對後端大佬的描述挺有意思，是這麼說的：左手高併發，右手高可用，頭頂中介軟體，腳踩微服務，懷抱雲原生，這就是大佬的全套戰甲。
所以你看看，後端圍牆高築，把妄圖橫插一腳的前端擋在了門外。至此後端深耕，前端也在不斷的嘗試中找到了自己的方向，大家各自幹各自領域的事情，互不糾纏。
但是 Serverless 特別是 FaaS 出現以後，這個平衡開始出現了微妙的變化。
應用交付工程師
什麼是“應用交付工程師”？
首先宣告一點，這個不是官方概念，是我在思考前端向後發展時萌生的。
我們上面說了，傳統前端工程師的職責，就是把設計圖做成網頁，但隨著 Node.js 出現，前端開始有更多的機會接觸到後端。對於某些小應用，一部分優秀的前端可以靠自己完成前端和介面，然後上線，不需要後端參與。
這部分人我們可以稱作是“全棧工程師”。所謂的全棧要麼是一端深一端淺，要麼是兩端都淺（當然超級大牛忽略），所以開發小應用可以，大型生產應用就沒全棧什麼事了。
而現在隨著 Serverless 雲函式橫空出世，遮蔽了伺服器和後端應用的部分，使後端開發門檻大幅降低。前端彷彿又看到了希望，我們可以不用寫介面，只需要編寫雲函式，也能實現生產應用的後端開發。
以前有高牆，前端卷不進來。現在牆拆了，你說我們進不進？
典型的例子是微信小程式雲開發。前端在微信開發者工具上編寫雲函式，一鍵上傳與部署。然後在小程式程式碼中獲取並呼叫這個遠端函式，相當於整個流程前後端都是自己實現自己除錯，直到應用開發完成。這就是一個典型的“前端工程師”轉變“應用交付工程師”的例子。
使用 Serverless 雲函式不光能輕鬆實現後端的業務功能，而且監控，併發，負載這些由雲廠商統一實現，一應俱全。因此在穩定性可靠性上也非常有保障。
還有一點，目前可能是大家的觀念問題，認為單獨的雲函式服務需要自己付費，還不如自己直接在雲伺服器上部署應用。事實上函式計算是按照呼叫次數，訪問流量計費的，比雲伺服器要更節約資源更省錢。
這個觀念我認為 2022 年會在大廠推動下逐步放開，越來越多的 web 應用也會接入 serverless，因此更多的前端開發工程師會轉變為應用交付工程師。
以前前端要實現一些自己的想法，必須要有後端的介面配合，而且還需要後端或運維幫忙線上上部署。但是現在不用了，我們有機會自己搞定這一切。我覺得這對前端來說是巨大的機會，一個可以將產品和自己的想法，直接產出一個應用的好機會。
除此之外，前端的協作模式可能也會發生變化。以前的一個大應用，前端組是分模組開發。但是現在有了 Serverless，再加上去年已經逐步成熟的微前端，前端協作模式很可能由 “一個模組一個模組開發” 變成 “一個應用一個應用開發”，這是一件非常酷的事情。
還有向前擴充時培養的產品思維，前端未來可能是最瞭解整個應用的人，所以前景不必多說。
加油吧，前端人們！2022 祝大家升職加薪，再攀高峰！
我想學更多
為了更好的保護原創，本文會首發微信公眾號 前端砍柴人。這個公眾號只做原創，每週至少一篇高質量文章，方向是前端工程與架構等實踐與思考。
除此之外，我還建了一個微信群，專門提供對這個方向感興趣的同學交流與學習。如果你也感興趣，歡迎加我微信 ruidoc 拉你入群～