如果你还不知道什么是Edge Function，你可能已经OUT了

如果你常常上github关注开源项目，你应该对Vercel这个公司不陌生，尤其当你做过一些较高关注度的项目的contribute，那么大概率看到过一些Vercel的bot自动部署你的分支。而如果你进一步点进去Vercel的官网看过一些他们提供的服务，你大概率会看到一个关键词：Edge。这就是我们今天要聊的话题，Edge Function，一个在国外热度非常高的基础设施，不仅仅只有Vercel一个公司在提供这个服务，类似于Netify，AWS都有提供类似的服务，那么他到底是什么以及为什么我们要使用他呢？

Edge Function VS CDN

为什么我要拿他和CDN来比较呢，因为Edge Function首先倡导的就是让你的服务离用户更近一点，这和CDN非常类似，而国内开发者大多对CDN还算熟悉，我们熟知的把前端资源打包然后丢CDN其实也是CDN使用的一部分。

那既然他们主打都是让你的资源离用户更近一些，那么他们的区别在哪里呢。那主要的区别在于功能上。CDN是一个完全基于HTTP的内容缓存服务，他们并不处理任何业务逻辑，只是代理了你的HTTP服务，然后把你的响应根据你设置的头来配置缓存。比如如果你在response的header里面设置了Cache-Control: s-maxage: 60s，那么CDN会缓存你这个响应，并且在未来60秒内对相同的请求直接返回缓存的内容。注意：这里的相同请求只需要请求内容匹配即可，不需要考虑是不是不同终端发起的请求。

而Edge Function是具有计算能力的，你可以部署函数到这个环境，当一个请求打到这个地方，你可以执行一些服务端的代码来产出对应的结果。Edge Function非常类似于Serverless，提供一个runtime让你可以一定程度上运行代码，其区别在于相较于真正的Serverless，他的runtime因为要部署在边缘节点上，所以去掉了很多功能只保留了核心的功能，这一方面保证了边缘节点的轻量化，另一方面也让Edge Function更快。

对前端的影响

一句话：Edge Function把前端扩展到了HTTP Server端。

传统前端的产出是打包完的前端资源，html/css/js 之类的，然后通过一个静态服务器让用户可以访问到这些资源就行，因为用户下载这些资源就可以运行你的代码。而如果我们需要使用SSR这样的技术在服务端渲染，我们就需要有一个服务器，引入服务器就引入来一系列的问题，比如服务器部署，服务器稳定性，以及最重要的：你的服务器如何离用户更近（让你的访问更快）。

而Edge Function让这些问题都得到了很好的解决，你只需要上传你的代码函数就可以运行，Edge Function可以随意扩展，并且他们原生就运行在边缘节点之上，本来就离用户更近。

当然你采用Edge Function并不代表你就不需要考虑部署了，你也要有一套编译上传的流程，但相较于传统的部署模式，你不需要进程管理监控等复杂的并且不是前端范畴的内容，即便你只是一个“可怜的”前端开发者，你仍然可以很容易地发布你的应用并且稳定运行，并且其访问性能几乎拉满。

带来的变革

现在国外基于Edge Function带来的技术方向升级已经非常成熟并且百花齐放。最典型的例子就是Nextjs，其本身就是Vercel开发的基于React的框架，所以其设计之初就非常契合Edge Function，如果你使用Nextjs开发，并且你把你的网站部署在Vercel上面，只需几行代码就能让你的代码直接运行在Edge， 让你的网站访问速度非常快。

在最近Vercel的开发者还提出了一个，Framework决定基础设施的论调，为了让你的网站访问更快，部署更简单，你的基础设施就应该适应这样的趋势，二Edge Function就是这样的场景下产生的。

而Edge Function其本身有计算能力，而Nextjs这一类的框架本身具备Fullstack的能力，所以把服务端移向Edge的呼声也越来越高。要把服务端都移向Edge一个最主要的blocker是数据库访问。传统的数据库访问都要通过driver，而这些driver大部分都不是原生JS的，而Edge runtime不会支持link这些第三方语言的包，因为他们太大又太慢了。不仅仅这种方式不适合Edge Function，即使是传统的Serverless Function，因为冷启动时间太长，引入这些driver也会导致其访问速度大降。

为了解决这个问题，则催生出了新的技术方向，Serverless Database。当然与其说是Database，应该说其只是一种Database的连接方式，大部分现有的实现就是在Database connection pool的基础上，增加一层HTTP的代理，让用户可以通过HTTP代理的方式来对对服务进行访问，然后把请求内容转移到本地的database connection上面来完成请求，比如最多关注的是plantscale的database js，以及最好用的ORM库Prisma提供的data proxy服务。如果你使用这些服务，那么你的代码就无需包含这些庞大且启动很慢的数据库driver，只需要最轻量的HTTP库的支持就可以。而且机遇HTTP方式的代理可以让数据库提供商也跨区域部署集群，让你的用户更快速地获取内容。

国内的情况

然而上面这些听起来非常激动人心的技术迭代，在国内却几乎看不到什么水花。以我比较浅薄的工作经验来说，国内使用Nextjs，Nuxtjs之类的Meta Framework的公司都很少，目前仍然以SPA的前后端分离方式为主。究其原因我认为有两点：

• 一是国内基本公司都以APP为主，主要做私域流量，对SEO的需求不大，并且国内搜索引擎的情况大家也都知道，不花钱你指望自然搜索流量其实很难，而且越来越多的人不再使用搜索引擎了，导致针对搜索引擎的优化变得可有可无，所以SSR的需求也变少了。同时国内做技术类的创业公司少，并且也非常难盈利，这些技术方向的推手也就很少，更别说国内技术领头羊的几家大公司也都是做私域流量为主的，他们的技术方向自然也是为这些场景服务，而很多创业公司的初期开发人员很喜欢这些大厂出来的人，自然也继承了这些技术方向。在这样的环境下这些技术生存的土壤就很少。

• 二是国内的市场主要集中在中国这个大的单一市场，虽然中国很大但是相较于全世界来说，还是相对集中的，即便你把网址部署在海南，在北京访问也不会显得非常慢，不像中国访问美国服务器这样。那么对于边缘节点的需求自然没有做全球市场的国外那么迫切。

当然这只是我的一家之谈，并不代表其一定正确。

但是很可惜的是，看着国外这方面技术发展越来越快，身边却没有什么人关注，只能眼睁睁看着国内越来越落后，心理不免还是有点感叹。

总结

最后，虽然作为公司打工人，我们可能用不到这些前沿的技术，但是作为开发者，我们还是要保持自己进步的动力，去尝试学习使用这些技术，现在的年代瞬息万变，你不知道什么时候就会有大的变化发生。相比于天天感叹前端已死，不如多看多试，更好地武装自己，才能长久地保持竞争力。

在 原文地址 获得更完善的阅读体验。

我是Jokcy，跟上技术发展的脚步，开拓技术学习的深度，想和我聊聊技术？WX ILoveDevelop 等你。