Edge 函数现状 2023 年：全球分布式应用之年
今年早些时候，我们启动了首届 Edge 函数现状调查，我们邀请开发者分享他们关于 Edge 函数的经验和预测。 收到近千份回复后，我们已结束调查，并很高兴发布报告。 鉴于Edge 函数是一项新兴技术，我们希望该报告能够深入了解常见的用例、痛点和即将到来的趋势。
请继续阅读我们的分析，或查看完整的调查结果。
没有参与今年的报告？请在下次调查开始时获取通知。
Edge 函数作为“胶水代码”
将 API 和数据库粘合在一起是最常见的用例，其次是身份验证和负载均衡
将 API 整合在一起不仅是 Edge 函数的常见用例，也是一般无服务器函数的常见用例，因为创建和部署许多单用途函数作为微服务，使开发团队更容易快速构建和交付。
身份验证是 Edge 函数的第二个被提及的用例，这在单源无服务器函数中可能不常见，因为 Edge 函数的延迟极低。 用户身份验证对于绝大多数应用程序至关重要，需要高性能以获得无缝的用户体验，而 Edge 函数在这方面具有独特的优势。
随着边缘无服务器生态系统的持续发展，我们将看到更多特定于边缘、特定于用例的中间件，例如这个最小依赖的身份验证解决方案。
更复杂的 Edge 函数需要状态
对于更复杂的用例，状态是最重要的需求
这是有道理的，因为持久数据存储解锁了一类全新的用例，例如在边缘托管整个 Web 应用程序。 特别提到的技术包括 Workers KV、Workers D1 和 PlanetScale。
为了在边缘快速构建有状态的应用程序，Deno KV 是一种全球分布式、零配置的 KV 存储，允许您使用单行代码连接到它，而无需复制和粘贴任何密钥。
Edge 函数意味着更好的性能
大多数开发者依靠 Edge 函数来提高网站速度和性能，其次是节省成本
每一毫秒的延迟都很重要，尤其是在电子商务、游戏、媒体网站等领域，这些领域都关系到真金白银。 通过在边缘运行函数（更常见的是整个 Web 应用程序）来消除网络延迟所带来的性能提升，对于开发者、他们的用户和他们的业务来说，无疑是一个巨大的附加价值，这是可以理解的。
首字节时间 (TTFB) 不仅大大缩短，而且借助诸如 Fresh 等边缘原生全栈 Web 框架，默认情况下不会向客户端发送任何 JavaScript，并且所有页面都是服务器端渲染的，开发者可以构建实现完美 Pagespeed 分数的电子商务应用程序并最大化收入。
大多数开发者在调试、测试和可观测性方面遇到困难
调试、测试和可观测性是开发者最常提到的挑战
对 Edge 函数进行故障排除的挑战出现在两个方面：Edge 函数提供商缺乏有用的日志记录和辅助工具，以及缺乏专注于 Edge 函数的第三方工具。 目前，Edge 函数的监控仍然依赖于为服务器或虚拟机设计的工具，例如 New Relic、Spunk 或 Sentry。
虽然测试单个 Edge 函数或微服务可能很简单，但由于当前测试框架的限制，验收测试、集成测试和 e2e 测试都很困难。 为这些情况创建可靠的测试通常需要开发团队构建自定义测试解决方案。
全规模应用在边缘成为现实
大多数受访开发者已经在边缘构建和部署了完整的 Web 应用程序
此外，超过一半的受访开发者认为，新的网站和应用程序将在未来 3 年内完全在边缘运行。 我们对此表示赞同，因为 Web 基础设施——从地下室的机器到云端的无服务器，再到边缘的无服务器——从历史上看都趋向于改善用户性能。
随着边缘无服务器计算的工具和生态系统的成熟，用例将从 CDN 代理、API 服务器和负载均衡器演变为全栈 SaaS、电子商务、Web 应用程序等，这归功于性能和用户体验的提升。
虽然构建全栈应用程序的许多方法通常将静态 JAMstack 与用于动态功能的 Edge 函数相结合，或者使用像 HonoJS 或 Fresh 这样的边缘原生框架，但我们预计会出现更多用于全球分布式全栈 Web 应用程序的工具，例如为边缘构建的 SaaS 模板 SaaSKit。
下一步是什么
感谢所有参与调查的开发者，感谢你们通过为报告做出贡献来回馈无服务器社区。 如果您想在明年调查和报告发布时收到通知，请在此处订阅 Edge 函数现状新闻通讯。
不要错过任何更新 — 在 Twitter 上关注我们。