作者｜Alessandro Segala
譯者｜王強
歷史總是喜歡重演。
我在 1999 年建立了自己的第一個網站，使用的是當時的 Web 高手（這裡我還沒法用“開發者”這個詞）能接觸到的最先進技術：所見即所得的編輯器。對我（以及許多其他許多人！）而言，這種技術最早指的就是微軟 FrontPage——現在回想起來，我的臉上還會浮現出摻雜著懷舊和羞愧的尷尬笑容。那時我的網站是一堆靜態 HTML 頁面，外加足量的 JavaScript 和酷炫的 GIF 的組合（它們在 2000 年的互聯網上就是最靚的仔），放在靜態託管服務商的平臺上——我用的是意大利的 Geocities 同類服務。在接下來的幾年裡我逐漸成長，有了更好的選擇，比如說 2002 年發佈的 Macromedia Dreamweaver MX（現已併入 Adobe）， 它的最大優點是其生成的代碼更加符合標準。
十年後的 2009 年，我仍在構建網站，但那時的關鍵詞是 動態。所有頁面都是使用 PHP 在服務端生成的。不只是 PHP，開發者正在以.NET、Java、Python、Ruby……構建全棧式 Web 應用。這些技術並不是全新的。ASP 自 1996 年以來就已經存在，PHP 則誕生於 1994 年！但在 2005—2010 年，一系列旨在簡化 Web 開發工作的框架湧現，使得更多的小型團隊和個人開發者開始有能力應用這些技術，例如 Django 和 Ruby on Rails 就是在 2005 年問世的。此外，那些年我們看到針對動態站點真正廉價的託管方案（如 Bluehost 這樣的共享託管商，成立於 2003 年）開始出現了，因此開發者不必再管理自己的服務器。當時，雲計算仍然是一種相對較新的事物，基本上屬於基礎架構即服務的類型。
快進到今天。現在是 2019 年，開發者現在正在再次構建靜態網站。你可能會把這種現象稱為尼采的永恆輪迴在 Web 開發行業的映射。但這次情況有所不同：拜更新的 HTML、JavaScript、CSS 標準和 API 所賜，Web 瀏覽器的能力大大超過了 20 年前。我們可以構建出運行在 Web 瀏覽器中的極其複雜的應用，從電子表格到 3D 遊戲無所不包，而且我們無需依賴外部插件。（我們也會像當年一樣大量使用 GIF，但這一次是為了嘲諷！）
JAMstack 和孤立的前端
HTML5 的初稿發佈於 2008 年，自那時以來，瀏覽器供應商一直在不斷實施新的 Web 標準，不停向 Web 中添加各種 API。從比較“基本”的東西（例如對 Adobe Flash 的衰落做出了巨大貢獻的 video 標籤）到對 Web 構建方式提出的基礎性修改提案（如 WebAssembly），不斷湧現的新事物使開發者常常很難掌握最新的可用技術。
不過進步之一是針對 Web 應用的新設計範式的普及，它被稱為 JAMstack：JavaScript、可複用 API 和預渲染的標記（Markup）。這種範式的靈感來自於移動應用，其理念是 Web 應用也應該完全隔離前端與後端層，兩者間僅通過一組協議接口，經由 HTTPS 通信。
JAMstack 的 JavaScript 部分應該是很容易理解的：整個應用程序都在客戶端（即 Web 瀏覽器）運行，並由 JavaScript 驅動（你也可以推廣這個定義，把它看成是瀏覽器中執行 JS 代碼的虛擬機，這樣也能把 WebAssembly 算進來）。
其中的“A”絕對是最有趣的部分，指的是 API：它們使 JAMstack 應用具有交互能力，併為用戶提供出色的體驗。你的靜態應用可以通過 HTTPS 調用的 API 與其他服務交互。最簡單的例子是 RESTful API，這些 API 很容易構建和使用。最近 GraphQL 越來越流行，在用圖形表示數據時它很好用（它是 Facebook 發明的，這並不是巧合）。對於需要交換大量結構化數據的場景來說，協議緩存和 gRPC 是另一種選擇，儘管它們目前需要代理才能與 Web 瀏覽器搭配工作。最後，實時應用可能會用到 WebSocket。你可以自由選擇想要的任何 API 格式，只要它適合你的需求即可。
說到 API，一個非常重要的細節是它們可以屬於任何人。你的應用可能正在與你（或後端團隊）構建和維護的 API 交互。或者你可能正在使用一些第三方 API，例如 SaaS 應用程序提供的選項。我們稍後將重點介紹這些內容。
最後，JAMstack 中的“M”指的是預渲染的標記（pre-rendered Markup）。Web 應用是一些靜態 HTML 文件的組合，這些文件通過各種構建工具（如 Webpack、Parcel 或 Rollup）在“構建時”預渲染。還可以從 Markdown 文件渲染內容，Hugo、Gatsby 和 Jekyll 這類靜態站點生成器就是這樣做的。在應用部署之前，所有預處理工作都在開發者的機器或持續集成（CI）服務器上執行完畢。
使用 JAMstack 編寫的應用一旦被“編譯”，就只是一堆 HTML、JavaScript 和 CSS 文件，以及所有附帶的資源（圖像和附件等）。任何時候都沒有服務端處理過程。這給 JAMstack 應用帶來了巨大的好處。
首先，JAMstack 應用非常易於部署、擴展和運營，並具有出色的性能。你可以從雲對象存儲服務（例如 Azure Blob 存儲或 AWS S3）交付靜態文件，這些服務非常便宜（每 GB 數據的月費很低），且高度冗餘和可靠。使用對象存儲服務時，你也不需要管理和修補服務器或框架，從而減少了開銷並提升了安全性。然後你在對象存儲前放一個 CDN（內容分發網絡），你的網站就會由世界各地的多個終端節點直接提供服務和緩存，最大程度減小了全球所有訪問者的延遲，並且可擴展性極佳。如果你願意，也可以像我一樣通過行星際文件系統（IPFS）提供文件。
其次，JAMstack 的開發者體驗（DX）如絲般順滑。對於初學者來說，前端和後端開發者都可以專注於自己的代碼，只要他們約定好接口和 API，基本上可以實現自主運營。帶有複雜模板引擎（還記得 PHP 嗎？）的單體應用的時代已經一去不復返了，彼時那種引擎只會給兩邊的團隊帶來衝突和煩惱。由於前端應用在“編譯”之後最終只是一堆靜態文件，因此它們也很容易進行原子部署。宏觀來說，你可以將新包複製到存儲區，然後更新 CDN 以指向新資產。前端應用的“編譯”過程往往很快，並且無需操心容器化和容器編排以及 Kubernetes 等。考慮到工具的標準化程度，建立持續集成和持續交付（CI/CD）管道通常非常簡單，這要歸功於預製模板。最後，前端開發者可以自由進行實驗，在某些情況下，他們甚至可以將開發前端指向生產後端。
要的就是速度
對最終用戶而言，這種模式真正的好處是構建出讓人感覺運行飛快的應用。這不僅可以提高用戶滿意度，還可以提高用戶的參與度和保留率。
可以從三個方面來解釋為什麼人們會感覺應用運行得很快。
首先，應用本身是異步加載數據的，因此用戶可以在加載數據時看到界面，並可以與其交互。看一下新的 Twitter 應用加載時的 GIF：
應用本身幾乎是立即加載的。然後它開始逐漸異步請求數據，並填充界面中的所有部分。
第二個原因是全方位緩存應用的能力。對於許多 JAMstack 應用而言，JavaScript 和 CSS 文件不會經常更改，因此客戶端在下載它們後可以將其緩存很長時間。這樣可以節省請求應用代碼所需的時間，因此客戶端只需提取數據即可。此外，如果 Web 應用是通過 CDN 提供的，則它允許用戶從更靠近他們的終端節點獲取你的代碼，從而大大減少了延遲。即使應用的代碼體積可能很大，但從 CDN 下載它的延遲變短，又能在本地緩存文件，實際上意味著應用的速度會更快。
至於緩存，你還可以使用 Service Worker 等技術來實現應用代碼和（某些）數據的緩存，以進一步加快頁面加載速度，甚至提供脫機體驗。
最後，API 服務器不需要浪費時間來生成和提供完整的 HTML 頁面，它只需要處理原始數據（通常是 JSON 負載，並在傳輸過程中使用 gzip 壓縮）即可，讓客戶端來完成頁面的構建過程。當你將資產包含在對象存儲服務中時，後端服務器不會收到對靜態資產的所有請求，因此它有更多資源來處理實際的業務邏輯和 API。
你可能不需要自己的 API
我在上面寫道，JAMstack 中的“A”代表 API，並且你可以使用任何人構建和運營的 任何 API。
你可以使用外部身份驗證服務來驗證用戶的身份。如果你構建的是企業應用，你的目錄可能已經在 Azure AD 或 G Suite 目錄中了（或與之同步）。對於消費類應用，請考慮使用諸如蘋果、Facebook、GitHub 等社交平臺的登錄服務。還有 Auth0 和 Okta 之類的公司提供了功能強大且可擴展的解決方案，包括帳戶管理（註冊表單、密碼重置……）和集成多種第三方服務的功能。好消息是，還有許多 API 可以支持上述某家或某些服務提供的身份驗證令牌，因此你可以立即進行集成。另外不管怎麼說，使用外部身份驗證服務，而不是編寫自己的身份驗證代碼是一個好主意，因為這是最安全的做法。
然後，你可以集成大量的 SaaS 服務，從而使你的應用訪問大量的數據和功能，你自己卻用不著做什麼工作。
還有用來播報天氣和交通信息、顯示股票價格和地圖、監控航班，甚至訂購比薩的 API。你可以使用 Google Analytics 或 Adobe Analytics 來監測網站的流量。如果你要建立一個博客，則可以使用 Disqus 或 Commento 之類的服務，讓用戶輕鬆地對你的帖子發表評論。
如果你需要 CMS 來簡單、動態地修改網站內容，則在“無頭內容管理系統”中有多種選項可選，例如 Strapi 和 Ghost。甚至無處不在的 WordPress 也支持無頭模式。
對於企業應用，與微軟 Office 365 和 G Suite 之類的 Office 套件集成後，你就可以發送和接收電子郵件、管理日曆和聯繫人、創建文檔和電子表格並訪問企業目錄等等。這些服務還附帶了 OneDrive 和 Google Drive 中的雲存儲空間，因此你可以輕鬆地使用它們來存儲和獲取數據。
開發者還可以依靠外部服務來完成以下工作：接受信用卡付款（Stripe）、轉換文件格式併為圖像生成縮略圖（例如 CloudConvert）、處理視頻、發送消息（例如通過 Slack、Teams、Twilio 等）……列表是無止境的。還可以從前端應用直接訪問某些數據庫服務，如 Firestore。
最後，你還可以將某些“低代碼 / 無代碼”服務用於服務器環境中必要的所有處理工作，比如有時它們需要連接客戶端無法直接訪問的服務（數據庫和某些企業應用等）。一種解決方案是 Azure Logic Apps，它本質上是針對開發者和企業的 IFTTT，你可以通過一個 REST 調用來觸發它。
使用外部服務提供 API 的好處是顯而易見的。現在，確保 API 可用並按需擴展成了其他人的責任。你無需修補任何應用程序或框架，更不用說基礎架構了，還會有一支團隊專門保證它們的安全性。
還有一些有趣的好處是關於隱私與合規話題的。如果你的應用只限於客戶端，也不存儲任何數據，則符合 GDPR 規範的責任大都是由你所依賴的服務提供商承擔的， 比如使用 Stripe 這樣的外部服務付款時，你就用不著操心 PCI-DSS 的問題了。
當然，如果沒有其他選擇，你也可以構建自己的 API。有了 無服務器 平臺（例如 AWS Lambda 和 Azure Functions），你就無需管理和擴展自己的服務器了——雖說你還是需要負責某些事情，比如說要修補應用程序，確保其在受支持的運行時上運行（你正在使用的 Node.js 版本到期後，你就得支持新版了），有時還要考慮如何對這些部署進行跨區域複製，並在各區域間平衡負載。建立自己的 API 時通常也需要自己管理數據存儲，這些數據存儲需要複製、備份和擴展。
接下來會是什麼：“JEMstack”
依靠我們自己的 API 和 / 或第三方 API 來使用 JAMstack 構建 Web 應用，是當今 Web 開發行業最先進的設計模式之一。我們用了幾十年時間將應用全面遷移到服務器內，並儘量將大部分工作從客戶端上移走，如今我們又開始將更多的任務放到瀏覽器中了。
有一個部分還是需要服務器的，那就是 API，不管是你自己的也好，其他人的也罷。接下來我們自然會問一個問題，那就是我們如何才能完全擺脫服務器？
最終的答案可能會是區塊鏈，具體來說就是以太坊。
我建議將這種模式稱為“JEMstack”，也就是 JavaScript、Ethereum（以太坊）和 pre-rendered Markup（預渲染標記）的首字母縮寫。這個技術棧將是“Web 3.0”或"分佈式 Web"的一部分。你的“JEMstack”分佈式應用（dapps）將通過 IPFS 提供服務，其數據將作為分佈式分類帳存儲在區塊鏈中。這樣做的好處包括讓用戶控制他們自己的數據，開發者也不必操心任何基礎架構。
但我們離這一步還很遠。你可以完全使用區塊鏈（尤其是以太坊）構建 dapp，事實上也已經有了很多 dapp。在 App.co 上有一個不錯的精選列表，但要讓這種技術成為主流，仍需要解決許多問題。
構建基於以太坊應用的開發者體驗（DX）確實很棒。應用可以簡單且無縫地調用智能合約來輕鬆訪問和更改存儲在區塊鏈上的數據。這類智能合約由為以太坊區塊鏈（在技術上來說是 E 以太坊虛擬機）編譯，並在以太坊區塊鏈上運行的代碼組成。智能合約可以存儲數據，並對其進行計算，這些合約通常使用稱為 Solidity 的類似 C 的語言編寫。
但在撰寫本文時，這種模式的終端用戶體驗（UX）仍有很大的改進空間，這是 dapp 廣泛流行的最大障礙，而且這種狀況可能還會持續很久。
首先，大多數用戶需要安裝瀏覽器擴展才能與以太坊交互，例如用於 Firefox 和 Chrome 的 Metamask，以及用於 Safari 的 Tokenary。只有一些用戶較少的瀏覽器（如 Brave 和 Opera）才提供對以太坊錢包的內置支持。移動是另一個雷區，用戶需要在平臺上下載特殊應用（如 Coinbase Wallet 或 Opera Mobile）才能與區塊鏈交互。
然後，用戶必須自己面對以太坊錢包。從以太坊讀取數據是免費且簡單的操作（並且不需要用戶交互），但是在區塊鏈上寫任何東西都需要得到用戶的手動批准，並至少要支付一筆“油費”。用戶需要支付一些以太坊代幣，才能執行使區塊鏈狀態發生變化的代碼，並且無論智能合約本身是否是用來支付的（也就是將資金轉移給其他人），這筆油費都是必需的。這樣的 UX 並不能使人愉快，它要求用戶點擊一個彈出窗口，然後等待幾秒鐘到幾分鐘才能被以太坊區塊鏈確認交易。而且，當然用戶需要首先購買以太坊代幣才行，實際做起來也不是那麼簡單，尤其是在世界上某些國家 / 地區更是麻煩。最後，如果用戶把錢包的私鑰或密碼恢復單詞放在了錯誤的地方，或者處理它們時不夠謹慎，還會存在安全隱患。
Meatmask 的用戶體驗中，確認彈框是常見的操作。
有一個龐大的社區正在致力於改善區塊鏈應用的用戶體驗，使其更容易添加用戶身份信息、建立更透明的流程、使交易更快甚至即時進行等等。就像所有發展初期的技術一樣，這裡也有很多區塊鏈技術、平臺和框架互相競爭。希望在接下來的幾個月和幾年中，我們能看到更多的融合和標準化進程，直到最後，用“JEMstack”寫出來的 dapp 可能會演變為新的規範。
原文鏈接：https://withblue.ink/2019/11/16/your-next-app-may-not-have-a-backend.html
閱讀更多 極光學苑 的文章
