Cloudflare一直致力于使Internet民主化。對我們來說，這意味著將最大的企業使用的最強大的工具帶到最小的開發部門。有時候，這似乎使我們的全球網絡能夠抵御大規模攻擊。在其他時候，這似乎為Internet用戶提供了簡單而可靠的隱私服務（如1.1.1.1）。上周，它看起來像Cloudflare Pages —一種快速，安全和免費的方式來構建和托管JAMstack網站。

　　我們看到Cloudflare Pages帶來了巨大的機會。它不僅使部署靜態站點變得盡可能容易，而且將其易用性擴展到了構建完整的動態應用程序。通過在Pages和Cloudflare Workers之間創建無縫集成，我們將能夠在Internet邊緣且與您的用戶接近的地方將前端和后端托管在一起。在林肯團隊加盟的CloudFlare幫助我們做到這一點。

　　今天，我們很高興宣布收購Linc，這是一個自動化平臺，可幫助前端開發人員進行協作并構建功能強大的應用程序。Linc使用前端應用程序捆綁包（FAB）進行了出色的工作，使前端開發人員可以更輕松地訪問動態后端。他們的方法為在Pages上構建端到端應用程序提供了一條簡單的途徑，將前端邏輯和強大的后端邏輯打包在一起。隨著Linc的加入，我們將加快Pages的開發速度，以支持更豐富，更強大的全堆棧應用程序。

　　將Cloudflare的邊緣網絡與Linc的服務器端渲染方法相結合，我們能夠通過向用戶靠近提供強大的服務器速度來為網絡性能樹立新的標準。現在，我將其交給Linc的首席技術官Glen Maddern，以分享他們為何加入Cloudflare。

　　設計Linc和前端應用程序捆綁包（FAB）規范時，只有一個目標：為前端開發人員提供最佳的工具，以構建，查看，優化和部署他們的應用程序。其中一個重要的方面是，無論您要構建哪種類型的應用，都應使服務器端邏輯更易于訪問。

　　靜態與動態前端

　　當今前端Web開發中的最大問題之一是，從生成靜態站點（例如，構建包含HTML，JS和CSS文件的目錄）到托管完整的應用程序（傳統上使用NodeJS和Web服務器）時，復雜性產生了巨大差異。像快遞）。雖然您可以靈活地為當前用戶按需呈現和自定義所有內容，但是卻增加了維護成本-現在，您需要保持運行的服務器。而且，除非您已經在全球范圍內開展業務，否則最終用戶的性能通常會很差，因為您的請求只能從全球一個或幾個位置得到滿足。

　　雖然已經出現了無服務器平臺來解決這些后端服務問題，并且可以將它們應用到前端應用程序上，但是它們比使用靜態托管的成本效益要低得多，尤其是在您的大部分前端資產是靜態的情況下。因此，我們在“ JAMstack”的總稱下看到了技術的興起。它們的目的是使靜態網站更強大（例如基于CMS更新進行重建），或者使隨服務器每次更新一起部署小的服務器端API（例如“云功能”）成為可能。但是從根本上說，它仍然是一個受限制的體系結構–您和您的用戶之間始終始終有一個靜態層，因此您的需求越動態，您的構建管道就越復雜，或者您越需要依賴于客戶端邏輯。

　　FAB采用了不同的方法：一種部署工件可以滿足服務器端的全部需求，從完全靜態的站點，具有某些API路由的應用程序或云功能，一直到完整的服務器端流呈現。我們還使其與您可能需要的所有云托管提供商兼容，從而使部署變得像上載ZIP文件一樣容易。然后，隨著需求的變化，動態內容變得越來越重要，隨著新框架的出現，這些框架將提供更高的性能，或者您考慮移動托管的提供商，則無需更改工具和部署過程。

　　FAB方法

　　無論使用哪種框架，FAB編譯器都會生成一個fab.zip文件，該文件包含兩個組件：充當服務器端入口點的server.js文件和存儲HTML，CSS的_assets目錄，發送到客戶端的JS，圖像和字體。

　　這種簡單的結構為我們提供了足夠的靈活性來處理各種應用程序。例如，靜態站點的server.js只有幾行自動生成的服務器端代碼行，僅足以為_assets目錄之外的任何文件添加重定向。另一方面，具有完整服務器渲染功能的應用程序外觀和工作方式完全相同。它的server.js文件中只有很多代碼。

　　在運行NodeJS的服務器上，提供已編譯的FAB就像fab服務fab.zip一樣容易，但是FAB的設計確實考慮了生產類托管。他們利用世界一流的CDN和周圍最好的無服務器托管平臺。

　　部署FAB時，通常將其拆分為這些組成部分，并分別進行部署。資產被發送到前面帶有CDN的低成本對象存儲平臺，服務器組件被發送到專用的無服務器托管。所有這些都以原子，冪等的方式部署，感覺就像上傳靜態文件一樣簡單，但是作為架構的一部分，可以完全解鎖動態服務器端代碼。

　　該通用架構運行良好，并且幾乎可以與周圍的每個托管平臺兼容，但是在Cloudflare Workers上的運作略有不同。

　　與其他無服務器平臺不同，工作進程真正在邊緣運行：它前面沒有CDN或負載平衡器以分離/ _assets路由并將其直接發送到Assets存儲。這意味著，無論是觸發完整頁面渲染還是通過圖像文件字節遍歷，每個請求都會命中工作程序。這似乎是不利的一面，但是對于Workers的性能和成本而言，情況恰恰相反-它實際上使我們在最終構建內容時具有更大的靈活性，并使我們更接近完全解鎖服務器端代碼的目標。

　　僅舉一個例子，我們不再需要將資產文件存儲在專用的靜態文件主機上，而是可以使用Cloudflare的全局鍵值存儲：Workers KV。然后，我們在Worker中運行的server.js可以將/ _assets請求直接映射到KV存儲中，并將結果流式傳輸給用戶。與代理第三方資產主機相比，這導致性能顯著提高。

　　我們發現，Cloudflare提供了最多的“ FAB本機”托管選項，因此，有機會進一步開發他們可以做的事情非常令人興奮。

　　Linc + Cloudflare

　　如上所述，Linc的目標是為前端開發人員提供最佳的工具，以構建和完善其應用程序，而無論他們使用的是哪個主機。但是我們開始注意到一個重要趨勢-如果團隊可以自由選擇在何處托管前端，他們必然會選擇Cloudflare Workers。在某些情況下，有一段時間，團隊甚至使用Linc在其現有主機旁邊向工人部署了FAB，以證明在永久遷移之前性能有所提高。

　　同時，我們開始看到越來越多的機會完全采用邊緣渲染，并使全球無服務器托管變得更強大，更容易訪問。但是，最激動人心的想法需要與托管服務提供商本身進行深度集成。這就是為什么當我們開始與Cloudflare進行交談時，一切都準備就緒的原因。

　　我們很高興加入Cloudflare的工作，并致力于擴展Cloudflare頁面以涵蓋所有應用程序。他們不僅分享我們為每個開發團隊帶來先進技術的目標，而且隨著諸如耐用對象之類的創新開始提供新的存儲范例，真正意義上的下一代部署，審查和托管平臺的潛力也將近乎完美。

　　詳情請訪問cloudflare中國官網（https://www.cloudflare.com/zh-cn/）