全文共6648字，預計學習時長19分鐘

"歷史總是驚人的相似，有重演之勢。"

一位科技界的大佬和小芯如是說。

我於1999年建立了第一個網站，用了一些可供網站管理員使用的最先進的技術（這種情況確實不能稱他們為開發人員）：所見即所得編輯器（WYSIWYG editors）。

對於我（還有很多人！ ）而言，這最初是指Microsoft FrontPage，而我正面帶尷尬的微笑，以一種懷舊又羞愧的心情告訴你這一切。

我的網站是一堆靜態的 HTML 頁面，這些頁面有很多 JAVAScript 和精彩的 GIF，它們在 20 世紀初的互聯網時代備受矚目，並且由靜態的託管者提供服務，這些託管者本質上相當於義大利的 GeoCities。

在接下來的幾年中，我逐漸做出了更好的選擇，例如2002年發佈的Macromedia Dreamweaver MX（也就是現在的Adobe）;其最大優點是生成更加符合標準的代碼。

十年後的2009年，我仍在建立網站，但動態是那個時候的關鍵。 所有頁面都是使用 PHP 在伺服器端生成的。 不只是PHP：開發人員當時也在用.NET，JAVA，Python，Ruby等構建全棧式網路應用程式。

這些技術並不完全是新技術：ASP 在1996年前後出現，而 PHP 在1994年首次亮相！ 但是，20世紀頭十年的後半期，正是在這個時候，有了簡化網站開發的新框架推動，更多的小型團隊和開發人員可以使用這些技術。

例如，Django和 Ruby onRails 於2005年問世。 此外，在那幾年，人們開始注意到動態網站的便宜主機託管選項（Bluehost這類共用主機開發於2003年），因此開發人員不必管理自己的伺服器。

當時，雲計算還是一個相對較新的事物，總之，它基本上都是基礎設施即服務。

快進到當今時代。 現在是2019年，開發人員現在正在...... 再次建立靜態網站。 你可能會稱其為網站開發領域的尼采永恆回歸的再現。

但這一次，情況有所不同：得益於更新的 HTML、JAVAScript、CSS 標準和 API，網路瀏覽器的功能遠遠超過了20年前。

現在，電子錶格和3D遊戲這樣極其複雜的應用程式可以開發出來並在網路瀏覽器中運行，而且無需外部外掛程式。 （大量的GIF也會再次使用，但這次暗含了一些諷刺意味！ ）

JAMstack 和 Isolated Front End

HTML5 最初發佈於2008年，自那時起，瀏覽器廠商一直在實施新的網路標準並向網站中添加 API。

改變體現於更多的"基本"事物，例如<video>標籤在很大程度上推動了Adobe Flash退出歷史舞臺，對WebAssembly之類的網路構建方式提出了根本性的建議，因此開發人員常常很難掌握最新消息以及可能發生的情況。

但是，最大的進步是網路應用程式新設計範式的推廣，這種新範式被稱為JAMstack，包括JAVAScript、可重用 API 和預渲染（pre-rendered）Markup。

該設想從移動應用程式中獲得靈感，即使網路應用程式的前端層與後端層完全隔離，人們也可以只憑藉一組商定的介面用HTTPS進行通信。

JAMstack 的 JAVAScript 部分所起的作用應該是不言而喻的：整個應用程式都在用戶端（即網路瀏覽器）中運行，由 JAVAScript 支援（你也可以更加概括地解釋此定義，就像解釋執行 JavaScript 代碼的瀏覽器中相同的 VM 一樣， WebAssembly也是如此）。

"A"絕對是最有趣的部分，它指的是API：API讓 JAMstack 應用程式具有交互性，並為終端用戶帶來非凡的體驗。 你的靜態應用程式可以通過 HTTPS調用的 API 與其他服務進行交互。

最簡單的例子是 RESTful API，它們易於構建、方便使用。 最近，GraphQL越來越流行，它對於可以用圖表表示的數據特別有用（其發明於Facebook 並不是巧合）。

對於某些情況，例如，那些需要交換大量結構化數據的應用程式還可以選擇Protocol Buffer和gRPC，儘管它們目前需要代理才能與網路瀏覽器一起使用。

最後，即時應用程式可能會利用WebSocket。 你可以自由選擇你想要的任何 API 格式，只要它滿足你的需求即可。

說到 API，一個非常重要的細節是任何人都可以擁有它們。 你的應用程式可能正在與你（或後端團隊）構建和維護的 API 進行互動。 或者，你可能正在使用第三方API，例如 SaaS 應用程式提供的 API。 稍後將重點介紹這些內容。

最後，JAMstack 中的"M"代表預渲染的 Markup。 網路應用程式是靜態 HTML 檔，在"構建時"通過各種打包工具（例如webpack、Parcel或Rollup）對這些檔進行預算。

Markdown檔中的內容也可以渲染，就像靜態網站生成器一樣，例如Hugo、Gatsby以及Jekyll。 在部署應用程式之前，所有預處理都在開發人員的電腦或持續整合 （CI） 伺服器上完成。

使用 JAMstack 編寫的應用程式一旦被「編譯」，就變成了一堆 HTML、JavaScript 和 CSS 檔，附帶著所有資源（圖像、附件等）。 伺服器端任何時候都不會處理。 這給 JAMstack 應用程式帶來了極大好處。

首先，JAMstack 應用程式極其容易部署、縮放和操作，而且它的性能極好。

你可以從雲端物件儲存服務（例如Azure Blob Storage或AWS S3）交付靜態檔，這些服務價格（每GB每月只需花幾便士）非常便宜，而且特別可靠。

使用物件存儲服務時，你也不需要管理、修補伺服器或框架，因此開銷減少了，而且安全性也提高了。

然後，將 CDN（內容分發網路）放在物件存儲的前面時，你的網站將由世界各地的多個終端節點直接提供服務和緩存，在全球範圍內，你網站的訪客將受到最小的延遲影響，此外，可擴充性也會達到極佳水準。

如果你願意的話，也可以像我一樣通過星際文件系統 （IPFS） 提供檔。

其次，JAMstack 的開發人員體驗（DX）很容易進行。 首先，前端開發人員和後端開發人員可以專心編寫自己的代碼，只要他們就介面和API達成一致意見，就基本上可以進行自主操作。

帶有複雜範本引擎（還記得PHP嗎？ ）的整體式應用程式時代已經一去不復返，這引起了兩個團隊間的衝突，讓大家都很頭疼。

前端應用程式在編譯後只是一堆靜態檔，因此它們也容易自動部署：級別較高時，你可以將新捆綁軟體複製到存儲區域，然後更新 CDN ，從而指向新資源。

前端應用程式的編譯速度往往非常快，無需擔心容器化技術、容器編排以及Kubernetes等問題。

考慮到工具的標準化程度，有了預製範本，建立持續集成和持續交付（CI / CD）管道通常很簡單。

最後，前端開發人員可以自由進行實驗，在某些情況下，他們甚至可以將開發前端指向生產後端。

一切都與速度有關

對於終端使用者而言，真正的獲益在於感覺到應用程式的快速運行。 這不僅可以提高用戶滿意度，還可以提高用戶的參與度和保留率。

為什麼會感覺到應用程式的快速運行？ 本文將從以下三個方面來解答。

首先，應用程式本身非同步載入數據，因此用戶可以在載入資料時看到介面，並可以與其進行互動。 下圖是新版Twitter 應用程式載入的動圖：

這個新的應用程式立即載入並非同步請求數據

該應用程式本身幾乎立即載入，然後逐漸開始非同步請求資料，並填充整個介面。

第二個原因是大量緩存應用程式的能力。 對於很多的JAMstack 應用而言，JavaScript 和 CSS 檔不會經常更改，所以客戶端下載應用後可以長時間緩存。

這樣可以節省請求應用程式代碼的時間，用戶端只需要提取數據即可。 此外，如果該網路應用程式是通過 CDN 提供的，那麼它會允許使用者從靠近他們的終端節點檢索你的代碼，極大地降低了延遲。

應用程式的代碼可能有好幾KB，即使如此，從CDN下載它的時間延遲降低了，還可以本地緩存檔，這實際上意味著該應用程式的運行速度變快了。

關於緩存，你還可以使用諸如Service Workers之類的更多技術來實現應用程式代碼和數據的緩存，進一步加快頁面載入速度，甚至提供離線體驗。

最後，API 伺服器不需要花費時間生成並提供完整的 HTML 頁面，它只需要處理原始數據（通常是 JSON payload，在傳輸過程中使用 GZIP 壓縮），而把構建頁面的工作交給用戶端完成。

將資源交給物件存儲服務時，後端伺服器不會收到對靜態資源的所有請求，因此它將擁有更多的資源來處理實際的業務邏輯和API。

你可能不需要自己的API

上面曾提到，JAMstack 中的「A」代表 API，而且你可以使用任何人構建和操作的任何 API。

你可以使用外部身份提供程式對用戶進行身份驗證。 如果你要構建企業應用程式，那麼目錄可能已經位於Azure AD或G Suite Directory（或與之同步）。

至於消費者應用程式，可以考慮與Apple、Facebook、GitHub這樣的社交平臺合作。

也有像Auth0和Okta這樣的公司，它們可以提供功能強大且可擴展的解決方案，包括帳戶管理（註冊表單、密碼重置... ）以及與各類外部供應商的集成。

令人欣慰的是，很多其他的 API 至少可以支援來自上述某些供應商的身份驗證令牌，因此你可以立即進行集成操作。 另外，無論如何，使用外部身份提供者而不使用自己的身份驗證代碼都是一個好主意，因為這種做法最安全。

然後，你可以集成大量的 SaaS 服務，這會使你的應用程式得以接觸到大量的數據，擁有更多的功能，而你這一端無需付出任何努力。

API 可以應用於天氣、交通、顯示股票價格、地圖、監控航班，甚至還可以用來訂比薩。

你可以使用 Google Analytics 或 Adobe Analytics 來計算網站的流量。 如果要創建部落格，那麼你可以使用Disqus或Commento之類的服務，從而輕鬆實現使用者對帖子的評論功能。

如果你需要內容管理系統來修改網站內容變得輕鬆愉快，那麼"無頭內容管理系統"可為你提供多種選擇。 例如，Strapi和Ghost。 甚至隨處可見的 WordPress 也可以在無頭模式下使用。

企業應用程式與Microsoft Office 365和G Suite等辦公套件整合後，你就可以收發電子郵件、管理日曆和聯絡人、創建文件和電子表格、訪問企業目錄等。

這些服務還附帶 OneDrive 和 Google Drive 中的雲端儲存，因此你可以輕鬆地使用它們來儲存和檢索數據。

開發人員還可以依靠外部服務來接受信用卡付款（如 Stripe）、在檔案格式之間進行轉換、為圖像生成縮略圖（例如CloudConvert）、處理視頻、發送消息（可通過 Slack、Teams、Twilio 等服務）......

API的功能是列不完的。 用戶可以從前端應用程式直接訪問某些資料庫服務，例如Firestore。

最後，你還可以將某些「低代碼/無代碼」服務用於伺服器環境一定需要進行的過程，因為它們需要連接用戶端無法直接訪問的服務（資料庫、某些企業應用程式等）。

一種解決方案是Azure Logic Apps，它本來是一個為開發人員和企業而設計的 IFTTT，你可以通過 REST 調用來讓它運行。

使用外部服務提供的 API 的好處不容錯過。 確保它們可用並根據需要進行擴展是其他人員的責任。

你無需修補任何應用程式或框架，更不用說基礎架構了，所有這些都會交給一個團隊來維護，從而保證其安全性。

關於隱私和合規性，還有一些有意思的好處。

如果你的應用程式僅存在於用戶端而未存儲任何數據，那麼 GDPR 合規性的責任多半將由你依賴的服務供應商承擔，就像使用外部服務付款一樣（如 Stripe），這讓你免於遵從 PCI-DSS。

當然，如果沒有其他選擇，也可以構建自己的 API。

借助無伺服器平臺，例如 AWS Lambda 和 AzureFunctions，你無需管理和擴展自己的伺服器，不過仍有負責的東西。

負責的內容包括修補應用程式，確保其在受支援的運行時上運行（例如：你使用的Node.js達到使用年限時，你要更新版本），可以視需要考慮如何地理複製這些部署和負載均衡。

構建自己的 API 通常也需要管理數據存儲，這些資料存儲需要經過複製、備份和縮放。

接下來是什麼？ JEMstack

依靠自己的 API 和/或第三方 API 來使用 JAMstack 構建網路應用程式，是當今網路開發過程中最先進的設計模式之一。

數十年來，人們一直在將應用程式完整地移動到伺服器上，並盡可能地將大部分工作從用戶端上移走，然後又將更多的任務放到瀏覽器上。

無論是你自己還是其他人，還需要伺服器的只剩下一個地方，那就是 API。 那麼按照邏輯，下一個問題是：「我們如何才能完全擺脫伺服器？ ”

答案是：最終可能通過使用區塊鏈實現，特別是乙太坊（Ethereum）。

我建議稱其為"JEMstack"，是 JAVAScript、Ethereum 和預算製 Markup 的首字母縮寫。

該堆疊將是「 Web 3.0」或分散式 Web 的一部分。 "JEMstack"分散式應用程式（或 dapps）將接受IPFS提供的服務，其數據將作為分散式總賬存儲在區塊鏈中。

其中的一些好處包括將數據的控制權交還給使用者，而且無論怎樣，開發人員都不必為基礎架構擔心。

以上這些還遠遠沒有實現。 你完全可以使用區塊鏈（尤其是乙太坊）構建 dapp，事實上，這樣的應用已經有很多了：http://App.co上有一個不錯的精選清單。 但是，要使此類技術成為主流，仍需要解決許多問題。

實際上，構建乙乙太坊為基礎的應用程式的開發人員經驗 （DX） 確實很棒。

應用程式可以通過簡單無縫地調用智慧合約來輕鬆存取和更改存儲在區塊鏈上的數據。 此類智能合約由一些代碼組成，它們為了乙太坊區塊鏈（從技術層面來說是以太坊虛擬機）而被編譯，之後在上面運行。

智能合約可以儲存數據並在上面進行計算，它通常由名為Solidity的語言編寫，這種語言與C語言類似。

但是，我在寫本文時發現，終端用戶體驗 （UX） 仍有很大的提升空間，這是廣泛應用 dapp 的最大障礙，該障礙可能還會持續更長時間。

首先，大多數使用者將需要安裝瀏覽器擴展來與乙太坊進行交互，例如 Firefox 和 Chrome 的 Metamask 和 Safari 的 Tokenary。 只有不那麼流行的瀏覽器（如 Brave 和 Opera）才提供對乙太坊錢包的內置支援。

Mobile 是另一個雷區，使用者需要在其中下載特定應用程式（例如 Coinbase Wallet 或 Opera Mobile）才能與區塊鏈進行交互。

然後，用戶必須處理乙太坊錢包。 雖然從乙太坊讀取數據既免費又便於操作（並且不需要使用者交互），但是在區塊鏈上寫入任何東西都需要得到使用者的手動批准，而且至少要支付"油費"。

使用者需要支付一小部分乙太坊代幣，才能執行改變區塊鏈狀態的代碼，而且無論智能合約功能本身是否可支付，這都是必需的（例如：它將資金（乙太幣）轉移給其他人）。

用戶體驗並不讓人滿意，因為它要求使用者顯式單擊彈出視窗，然後等待幾秒鐘到幾分鐘，以便乙太坊區塊鏈能確認交易。

當然，使用者需要先購買乙太坊令牌，這並不像看起來那樣簡單，尤其是在世界上某些國家或地區。

最後，如果使用者放錯了錢包的私鑰或還原了單詞，或不夠謹慎，都會留下安全隱患。

目前有一個龐大的團體正在致力於改善區塊鏈應用的用戶體驗，使其更容易添加身份，構建更透明的流程，使交易更快，甚至能瞬間完成。

每種技術仍處於不穩定狀態，而且現在存在著各種各樣彼此競爭的區塊鏈技術。 這與平臺和框架的情況很相似。

真心希望在接下來的幾個月和幾年中，會看到更多的融合和標準化，而最終寫在"JEMstack"上的 dapp 可能會成為新的規範。

小芯相信，有生之年，一定能看到的！

留言 點讚 關注

我們一起分享AI學習與發展的乾貨

編譯組：余書敏、周果相關連結：https://medium.com/better-programming/your-next-app-may-not-have-a-backend-aacc728bd032

如需轉載，請後台留言，遵守轉載規範