1. 首页
  2. css

CSS无服务器功能:超高效前端团队的秘诀

现代应用程序对前端开发人员提出了很高的要求。Web应用程序需要复杂的功能,而这项工作的大部分份额正落在前端开发人员身上:
– 构建现代,可访问的用户界面
– 创建交互元素和复杂的动画
– 管理复杂的应用程序状态
– 元编程:构建脚本、transpiler、bundler、linter等
– 从REST、GraphQL和其他API读取
– 中间层编程:代理、重定向、路由、中间件、身份验证、,等等。
这个列表本身就让人望而生畏,但是如果你的技术栈不为简单性而优化,它就会变得非常粗糙。复杂的基础结构会带来隐藏的责任,从而带来风险、减速和挫折。
根据我们选择的基础结构,我们可能会无意中添加服务器配置、版本管理、,而DevOps的其他职责则由前端开发人员承担。
软件体系结构直接影响团队的工作效率。选择能够避免隐藏的复杂性的工具,帮助团队完成更多任务,减少超负荷。隐藏的中间层—前端任务可以在其中迅速展开复杂性
让我们看看我看到的分配给多个前端团队的任务:创建一个简单的restapi,将来自几个服务的数据合并到前端的单个请求中。如果你对你的电脑大喊大叫,\”但那不是前端任务!\”-我同意!但我是谁让事实阻碍了积压?
只有前端需要的API属于中间层编程。例如,如果前端将来自多个后端服务的数据合并并派生出几个附加字段,那么一种常见的方法是添加一个代理API,这样前端就不会进行多个API调用,也不会在客户端执行一系列业务逻辑。
后端团队应该拥有这样一个API的界限并不明确。把它放到另一个团队的待办事项上——并在将来得到更新——可能是一场官僚式的噩梦,因此前端团队最终会承担责任。
这是一个故事,根据我们所做的架构选择,结局会有所不同。让我们看看处理此任务的两种常见方法:
– 在节点上构建一个Express应用程序来创建REST API
– 使用无服务器函数来创建REST API
Express+节点带来了惊人的隐藏复杂性和开销。无服务器让前端开发人员可以快速部署和扩展API,这样他们就可以回到其他前端任务中去了。解决方案1:使用Node和Express(以及Docker和Kubernetes)构建和部署API在我的职业生涯早期,标准操作过程是使用Node和Express来支持REST API。表面上看,这似乎相对简单。我们可以在一个名为server.js的文件中创建整个RESTAPI:
const = 8080;const = express();app.use(express.static(\”site\”));// simple REST API to load movies by slugconst => {const { slug = === slug);res.json(movie);});app.listen(PORT, HOST,>
This code isn\”t too far removed from front-end JavaScript. There\”s a decent amount of boilerplate in here that will trip up a front-end dev if they\”ve never seen it before, but it\”s manageable.
If we run node server.js,我们可以访问http://localhost:8080/api/movies/some-movie,并查看带有slugsome-movie(假设您在data.json中定义了它)的电影的详细信息的JSON对象。部署引入了大量额外开销
但是,构建API只是一个开始。我们需要以一种既能处理大量流量又不会崩溃的方式部署这个API。突然间,事情变得更加复杂了。
我们需要更多的工具:
– 在某处部署它(例如DigitalOcean、Google云平台、,AWS)
– 保持本地开发和生产一致性的容器(即Docker)
– 确保部署保持活动状态并能够处理流量峰值的方法(即Kubernetes)
此时,我们已经远远超出了前端领域。我以前做过这种工作,但我的解决方案是从教程或堆栈溢出答案复制粘贴。
Docker配置在某种程度上是可以理解的,但我不知道它是安全的还是优化的:
FROM node:14WORKDIR /usr/src/appCOPY package*.json ./RUN npm installCOPY . .EXPOSE 8080CMD [ \”node\”, \”server.js\” ]
接下来,我们需要弄清楚如何将Docker容器部署到Kubernetes中。为什么?我不太确定,但这是公司的后端团队使用的,所以我们应该遵循最佳实践。
这需要更多的配置(都是复制和粘贴的)。我们把自己的命运托付给谷歌,并按照Docker的指示将容器部署到Kubernetes。
我们最初的\”建立一个快速节点API\”任务已经膨胀成一系列与我们的核心技能不符的任务。当我第一次接到这样的任务时,我花了好几天的时间来进行配置,等待后端团队的反馈,以确保我没有造成比我解决的问题更多的问题。
一些公司有一个DevOps团队来检查这项工作,确保它不会做任何糟糕的事情。其他人最终相信了堆栈溢出的思想,并希望得到最好的结果一开始可以使用一些节点代码进行管理,但很快就会螺旋式扩展到跨专业领域的多层配置中,这远远超出了我们希望前端开发人员知道的范围。解决方案2:如果我们选择无服务器函数,则使用无服务器函数构建相同的REST API,故事可能会大不相同。Serverless是Jamstack web apps的绝佳伴侣,它为前端开发人员提供了处理中间层编程的能力,而无需考虑如何部署和扩展服务器的不必要复杂性。
多种框架和平台使部署Serverless功能变得轻松。我首选的解决方案是使用Netlify,因为它可以自动连续地交付前端和无服务器功能。在本例中,我们将使用Netlify函数来管理我们的无服务器API。
将函数用作服务(一种描述处理无服务器函数的基础结构和扩展的平台的奇特方式)意味着我们可以只关注业务逻辑,并且知道我们的中间层服务可以处理大量的流量不会摔倒。我们不需要处理Docker容器或Kubernetes,甚至不需要处理节点服务器的样板文件—它只起作用™ 因此,我们可以发布一个解决方案并继续我们的下一个任务。
首先,我们可以在***6***的无服务器函数中定义RESTAPI:
***7***
要添加正确的路由,我们可以在项目的根目录下创建***8***:
这比我们需要的Node/Express方法配置要少得多。我更喜欢这种方法的是,这里的配置被剥离为我们只关心的:我们的API应该处理的特定路径。其余的构建命令、端口等都是用良好的默认值为我们处理的。
如果我们安装了Netlify CLI,我们可以用命令***9***立即在本地运行它,它知道在***10***目录中查找无服务器函数。
访问***11***将显示一个JSON对象,其中包含有关\”booper\”电影的详细信息。
到目前为止,这与Node和Express设置没有太大区别。然而,当我们开始部署时,差别是巨大的。以下是将此站点部署到生产环境的步骤:
1. 提交无服务器功能,并将***12***提交到repo,并将其推送到GitHub、Bitbucket或GitLab上
2. 使用Netlify CLI创建一个连接到git repo的新站点:***13***

CSS无服务器功能:超高效前端团队的秘诀 为WP2原创文章,链接:https://www.wp2.cn/css/css%e6%97%a0%e6%9c%8d%e5%8a%a1%e5%99%a8%e5%8a%9f%e8%83%bd%ef%bc%9a%e8%b6%85%e9%ab%98%e6%95%88%e5%89%8d%e7%ab%af%e5%9b%a2%e9%98%9f%e7%9a%84%e7%a7%98%e8%af%80/