新舊交替，你敢相信？下一個應用程序可能沒有後端……

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

圖源：Unsplash

「歷史老是驚人的類似，有重演之勢。」

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

我於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年），所以開發人員沒必要管理本身的服務器。

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

圖源：Unsplash

快進到當今時代。如今是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 應用程序體系結構的概念概述

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）管道一般很簡單。

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

一切都與速度有關

圖源：Unsplash

對於終端用戶而言，真正的獲益在於感受到應用程序的快速運行。這不只能夠提升用戶滿意度，還能夠提升用戶的參與度和保留率。

爲何會感受到應用程序的快速運行？本文將從如下三個方面來解答。

首先，應用程序自己異步加載數據，所以用戶能夠在加載數據時看到界面，並能夠與其進行交互。下圖是新版Twitter 應用程序加載的動圖：

這個新的應用程序當即加載並異步請求數據

該應用程序自己幾乎當即加載，而後逐漸開始異步請求數據，並填充整個界面。

第二個緣由是大量緩存應用程序的能力。對於不少的JAMstack 應用而言，JavaScript 和 CSS 文件不會常常更改，因此客戶端下載應用後能夠長時間緩存。

這樣能夠節省請求應用程序代碼的時間，客戶端只須要提取數據便可。此外，若是該網絡應用程序是經過 CDN 提供的，那麼它會容許用戶從靠近他們的終端節點檢索你的代碼，極大地下降了延遲。

應用程序的代碼可能有好幾KB，即便如此，從 CDN 下載它的時間延遲下降了，還能夠本地緩存文件，這實際上意味着該應用程序的運行速度變快了。

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

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

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

你可能不須要本身的API

圖源：Unsplash

上面曾提到，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 的好處不容錯過。確保它們可用並根據須要進行擴展是其餘人員的責任。

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

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

圖源：Unsplash

若是你的應用程序僅存在於客戶端而未存儲任何數據，那麼 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，事實上，這樣的應用已經有不少了：App.co上有一個不錯的精選列表。可是，要使此類技術成爲主流，仍須要解決許多問題。

實際上，構建以以太坊爲基礎的應用程序的開發人員經驗 (DX) 確實很棒。

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

智能合約能夠存儲數據並在上面進行計算，它一般由名爲Solidity的語言編寫，這種語言與C語言相似。

可是，我在寫本文時發現，終端用戶體驗 (UX) 仍有很大的提高空間，這是普遍應用 dapp 的最大障礙，該障礙可能還會持續更長時間。

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

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

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

用戶須要支付一小部分以太坊代幣，才能執行改變區塊鏈狀態的代碼，並且不管智能合約功能自己是否可支付，這都是必需的（例如：它將資金（以太幣）轉移給其餘人）。

用戶體驗並不讓人滿意，由於它要求用戶顯式單擊彈出窗口，而後等待幾秒鐘到幾分鐘，以便以太坊區塊鏈能確認交易。

固然，用戶須要先購買以太坊令牌，這並不像看起來那樣簡單，尤爲是在世界上某些國家或地區。

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

確認彈出窗口是 Metamask UX的常見部分

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

每種技術仍處於不穩定狀態，並且如今存在着各類各樣彼此競爭的區塊鏈技術。這與平臺和框架的狀況很類似。

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

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

留言 點贊 關注

咱們一塊兒分享AI學習與發展的乾貨
歡迎關注全平臺AI垂類自媒體 「讀芯術」

（添加小編微信：dxsxbb，加入讀者圈，一塊兒討論最新鮮的人工智能科技哦～）