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/）