serverless 构建_使用Serverless，StepFunctions和StackStorm Exchange构建社区注册应用程序-Episode…...

serverless 构建

by Dmitri Zimine

由Dmitri Zimine

使用Serverless，StepFunctions和StackStorm Exchange构建社区注册应用程序-第4集 (Building a community sign-up app with Serverless, StepFunctions, and StackStorm Exchange — Episode 4)

Build a real-world serverless application on AWS with Serverless framework and ready-to-use functions from StackStorm Exchange open-source catalog.

使用无服务器框架和StackStorm Exchange开源目录中的即用型功能，在AWS上构建真实的无服务器应用程序。

Episode One | Episode Two | Episode Three | Episode Four

第一集 | 第二集 | 第三集 | 第四集

It took us three exciting episodes to create a non-trivial serverless app. The back-end now works, but two things are still missing: a Web UI, and a final discussion to sum up the lessons. Let’s continue… after a quick recap of the previous episodes:

我们花了三个激动人心的情节来创建一个非平凡的无服务器应用程序。 后端现在可以使用了，但是仍然缺少两件事：一个Web UI，以及一个总结课程的最终讨论。 让我们继续...快速回顾一下前几集：

• In Episode One, I described the application we are building, walked you through setting up the development environment and creating a Serverless project, and showed how to build your first Lambda function from a StackStorm Exchange action with Serverless Framework.

  在第一集中 ，我描述了我们正在构建的应用程序，引导您完成了开发环境的创建并创建了无服务器项目，并展示了如何使用无服务器框架通过StackStorm Exchange操作构建第一个Lambda函数。

• In Episode Two, we added more actions: one native Lambda to record user info to DynamoDB, and another one from StackStorm Exchange to make a call to ActiveCampaign CRM system. You learned more of serverless.ymlsyntax and practiced the development workflow with Lambda functions.

  在第二集中 ，我们添加了更多操作：一个本机Lambda将用户信息记录到DynamoDB，另一种Lambda从StackStorm Exchange调用ActiveCampaign CRM系统。 您了解了更多serverless.yml语法，并使用Lambda函数练习了开发工作流程。

• In Episode Three, we wired the actions with StepFunctions, learned tricks on passing the data between the steps, struggled debugging StepFunction executions, and finally got the backend working end-to-end.

  在第三集中 ，我们将动作与StepFunctions连接起来，学习了在步骤之间传递数据的技巧，费力地调试StepFunction执行，最后使后端能够端到端地工作。

You can get the final code for this episode from GitHub.

您可以从GitHub获取此剧集的最终代码。

添加Web UI (Add Web UI)

We need a web form that takes user names and emails, and posts to our StepFunction API Gateway endpoint. I just copied the one I used while exploring Serverless with Python, StepFunctions, and Web Front-end Serverless. Which, I confess, I grabbed from the old Serverless Slack Invite project.

我们需要一个使用用户名和电子邮件并发布到StepFunction API Gateway端点的Web表单。 我只是复制了我在使用Python，StepFunctions和Web Front-end Serverless探索Serverless时使用的脚本 。 我承认，这是我从旧的无服务器Slack邀请项目中获得的。

Those of you who are Web developers can surely create something more elegant with ReactJS — PRs welcome! Whether you build your own or grab mine, do this: create a directory web and place the static content there.

那些是Web开发人员的人一定可以使用ReactJS创建更优雅的东西—欢迎PR！ 无论您自己构建还是抢我的，请执行以下操作：创建目录web并将静态内容放置在其中。

I use http-server for a quick look that at my static form:

我使用http-server快速查看了我的静态表单：

cd webhttp-serverStarting up http-server, serving ./Available on:  http://127.0.0.1:8080

Open a browser, check the form at http://127.0.0.1:8080 , see that it comes out right, and let’s move on to the next step.

打开浏览器，检查位于http://127.0.0.1:8080的表单，确认它正确无误 ，让我们继续下一步。

How is a serverless web front end deployed to AWS? Typically, you put the static content on S3, configure it to serve the web, make your web app call your backend endpoint, and remember to enable CORS on API Gateway endpoint.

无服务器Web前端如何部署到AWS？ 通常，您将静态内容放在S3上，对其进行配置以服务Web，使Web应用程序调用后端端点，并记住在API Gateway端点上启用CORS。

Alternatively, you add a path to your API Gateway resource to serve your static web content from the S3 bucket.

或者，您可以向API网关资源添加路径，以从S3存储桶中提供静态Web内容。

Pros: 1) no mess with CORS, 2) no adjusting your web app to point to the correct backend endpoint. Extra bonus: easily done with serverless-apig-s3 plugin.

优点： 1)不会与CORS混淆，2)无需调整Web应用程序以指向正确的后端端点。 额外的好处：使用serverless-apig-s3插件轻松完成。

Cons: 1) paying API Gateway charges for web requests 2) the plugin is a bit shaky: fine for examples and small apps, but I wouldn’t use it for anything resembling production.

缺点： 1)为Web请求支付API Gateway费用2)插件有点不稳定：适用于示例和小型应用程序，但我不会将其用于任何类似于生产的事情。

PRO TIP: For serious web front-ends with high loads: deploy them to CloudFront. Or use something like Netlify — check out the recent post “How to build a static Serverless site with Netlify” from serverless.com.

专业提示：对于具有高负载的严重Web前端：将它们部署到CloudFront。 或使用Netlify之类的东西-查看serverless.com上最近发布的文章“如何使用Netlify构建静态无服务器站点” 。

I’ll use the API Gateway approach with serverless-apig-s3 plugin here: we don’t expect massive load. And it is simple. Watch:

我将在此处将API网关方法与serverless-apig-s3插件一起使用：我们不希望出现大量负载。 而且很简单。 看：

Install the plugin (been there, done that):

安装插件(在此完成)：

npm install --save-dev serverless-apig-s3

Change serverless.yml. Add the plugin (been there, done that). Add the plugin’s configurations:

更改serverless.yml 。 添加插件(在此完成)。 添加插件的配置 ：

...custom:  private: ${file(env.yml):private}  stage: ${opt:stage, self:provider.stage}  region: ${opt:region, self:provider.region}  apigs3:    dist: web    topFiles: true

...

plugins:  - serverless-plugin-stackstorm  - serverless-step-functions  - serverless-apig-s3

We are telling the plugin to pick our web directory and put it to S3. The topFiles flag tells API Gateway to expose our index.html and formsubmit.js at our endpoint, under /web/

我们告诉插件选择我们的web目录并将其放入S3。 topFiles标志告诉API Gateway在我们的端点/web/下公开我们的index.html和formsubmit.js 。

Now deploy the service, and, separately, the client side, with two commands:

现在，使用两个命令来部署服务以及客户端。

sls deploy

sls client deploy

Deploying the service will update the API Gateway with the paths to access our web content. Deploying the client puts the web content up to an S3 bucket. Now you can reason that if you add or remove web files and client deploy is not enough, a full sls deploy is required. But if you only change the web files, quick sls client deploy will put them up on AWS.

部署该服务将使用访问我们的Web内容的路径更新API网关。 部署客户端会将Web内容放入S3存储桶。 现在，您可以推断出，如果添加或删除Web文件并且客户端部署还不够，则需要完整的sls deploy 。 但是，如果仅更改Web文件，则快速sls client deploy会将它们放在AWS上。

That’s it! Go to https://YOUR-ENDPOINT.amazonaws.com/dev/web/index.html.The form is right there. The button is orange. You type in the user info and email, hit the orange button. The green message tells you everything is OK. Soon you receive an invitation from Slack. You check the StepFunction executions in AWS console and see everything is green.

而已！ 转到https://YOUR-ENDPOINT.amazonaws.com/dev/web/index.html. 表格就在那里。 该按钮为橙色。 您输入用户信息和电子邮件，然后单击橙色按钮。 绿色消息告诉您一切正常。 很快您就会收到Slack的邀请。 您在AWS控制台中检查StepFunction的执行情况，然后看到一切都是绿色的。

No?! Most likely, you hit this apig-s3 bug, just like I did. And just like I did, you got to do a little final step manually.

没有？！ 与我一样，您很可能遇到了apig-s3错误 。 就像我一样，您必须手动完成最后一步。

Open AWS Console ->API Gateway->Resources->Actions-Deploy API. Or use AWS CLI:

打开AWS控制台-> API网关->资源-> Actions-Deploy API。 或使用AWS CLI：

# Find out your rest-api-id firstaws apigateway get-rest-apis

# Deploy the changes to the stage# Don't COPY-PASTE, it needs YOUR ID!aws apigateway create-deployment --rest-api-id  YOUR_API_ID  --stage-name dev

Now it works for me.

现在对我有用。

PRO TIP: The plugin works when everything is deployed from scratch. But if you’re tempted to sls remove and redeploy again, you hit at least one other plugin bug on removing the stack. See Tips and Tricks at the end of the post on how to properly clean-up.

专业提示：当一切从头开始部署时，该插件即可工作。 但是，如果您想重新sls remove并重新部署sls remove ，则在删除堆栈时至少还会遇到其他一个插件错误 。 有关如何正确清理的信息，请参见文章末尾的提示和技巧。

Congratulations! You made it. You might have followed along and built your own app. You might have dropped it at some point out of frustration or fatigue. You might have just skimmed the text and examples. But if you made it to the end, you learned enough of serverless to be dangerous.

恭喜你！ 你做到了。 您可能已经遵循并构建了自己的应用程序。 您可能出于挫败感或疲劳而将其丢弃。 您可能刚刚浏览了文本和示例。 但是，如果最终做到这一点，您将学到足够多的无服务器危险。

反射 (Reflection)

After wrestling through all the 4 episodes, you likely sensed it: serverless is not simple. Many things can go wrong as you build a serverless app.

在经历了所有4集之后，您可能会感觉到：无服务器并不简单。 在构建无服务器应用程序时，许多事情可能出错。

You can blame some on me: I surely made a few mistakes and omissions (BTW reports and comments much appreciated!)

您可以责怪我：我肯定犯了一些错误和遗漏(非常感谢BTW报告和评论！)

But serverless complexity is not all my fault. We wire together many different services — AWS and 3rd party — with many different wires — frameworks and tools. The services are of different quality and [in]convenience (don’t get me started on AWS StepFunction CLI). The frameworks and tools are still maturing (which serverless plugin made you struggle the most?).

但是无服务器的复杂性并不是我的全部错。 我们将许多不同的服务(AWS和3rd Party)与许多不同的框架和工具结合在一起。 这些服务具有不同的质量和不便之处(不要让我开始使用AWS StepFunction CLI)。 框架和工具仍在成熟(哪个无服务器插件让您最苦恼？)。

Why get into serverless? Because for some classes of apps, it is substantially cheaper. This community signup is a case in point: we used to run StackStorm’s with StackStorm. It was simple to build and solid like a rock, but it took a m3.large instance at $100/month, without even getting to multi-zone reliability. With serverless it runs at less than $1/month, thanks to the occasional load pattern. $100 would buy us ~5,000,000 sign-ups — that’s more that we’ll ever need!

为什么要进入无服务器？ 因为对于某些类的应用程序，它要便宜得多。 该社区注册就是一个很好的例子：我们过去经常通过StackStorm运行StackStorm。 它的构建和坚固都像石头一样简单，但是它花了m3.large实例，每月100美元，甚至没有达到多区域可靠性。 使用无服务器，由于偶尔的负载模式，它的运行费用不到每月1美元。 $ 100可以为我们带来约5,000,000笔注册申请-这是我们永远所需要的！

On the other extreme, high volume apps with high reliability requirements might be better as serverless too, leveraging “infinite” elasticity which may be expensive to build and operate yourself. I carefully use “might” and “would”, as the equation varies greatly from case to case. Do your math upfront, watch your load patterns, explore your bill.

另一方面，具有高可靠性要求的大容量应用程序也可能像无服务器一样更好，它利用了“无限”的弹性，这对于自己构建和操作可能是昂贵的。 我仔细地使用“ may ”和“ will ”，因为这种情况因情况而异。 先进行数学运算，观察负载模式，研究账单。

As for taming complexity, Serverless framework helps. To fully appreciate it, try and redo the same app without it. Make it reliable, repeatable, reviewable infrastructure-as-code. While Serverless framework is not the only game in town, I specifically like it for it’s pluggable architecture and the plugin ecosystem.

至于驯服的复杂性， 无服务器框架会有所帮助。 要完全欣赏它，请尝试并重做一个没有它的应用程序。 使它成为可靠，可重复，可审查的基础架构代码。 尽管无服务器框架不是唯一的游戏，但我特别喜欢它的可插拔架构和插件生态系统。

Plugins help, picking up in areas not covered by the core Serverless framework. Using the plugins, we enjoyed the simplicity of building StepFuncions and adding simple web front-ends (and if you haven’t, try and redo it without the plugins). There are more: skim and bookmark the list of official plugins to keep them in mind when for your next project.

插件会提供帮助，帮助您解决核心无服务器框架未涵盖的领域。 使用插件，我们享受了构建StepFuncions和添加简单的Web前端的简便性(如果没有，请尝试在没有插件的情况下重做它)。 还有更多：浏览并标记官方插件列表，以便在下一个项目时记住它们。

StackStorm Exchange — the recent addition to the serverless ecosystem — brings a catalog of reusable integrations. While it is not hard to scrape APIs for ActiveCampaign or find and use undocumented Slack API calls, it is low-value work that takes away from building the application logic.

StackStorm Exchange (无服务器生态系统的最新成员)带来了可重复使用的集成目录。 虽然不难为ActiveCampaign抓取API或查找和使用未记录的Slack API调用，但这是一项低价值的工作，无助于构建应用程序逻辑。

Explore what is already there: while DevOps integrations dominate due to StackStorm roots in IT automation, I expect that variety will grow now that Serverless community is joining to contribute and co-pilot the catalog.

探究已经存在的内容：尽管由于StackStorm植根于IT自动化，DevOps集成占据了主导地位，但是我希望随着无服务器社区的加入，共同推动目录的开发和发展，多样性将会越来越大。

With that, we are officially done. Enjoy!

这样， 我们就正式完成了。 请享用！

其他一些技巧和窍门 (A few more Tips and Tricks)

• Removing everything will not remove the DynamoDB table. A reasonable default, but when you try and re-deploy the service, it’ll cry that the table can’t be created as it already exists. Delete it: aws dynamodb delete-table --table-name signup-stormless-dev

  删除所有内容不会删除DynamoDB表。 这是一个合理的默认值，但是当您尝试重新部署服务时，会因为无法创建该表而哭泣。 删除它： aws dynamodb delete-table --table-name signup-stormless-dev

• Due to an apig-s3 bug, sls remove will fail complaining that the bucket is not empty. Remove the web s3 bucket manually when removing a stack. aws s3 rb s3://bucketname --force

  由于apig-s3错误， sls remove将失败，并抱怨存储桶不为空。 卸下堆栈时，请手动卸下Web s3存储桶。 aws s3 rb s3://bucketname --force

• Removing the stack does not remove the DynamoDB table. If you really want to start from scratch, delete it manually (export the data first):

  删除堆栈不会删除DynamoDB表。 如果您确实要从头开始，请手动将其删除(首先导出数据)：

  aws dynamodb delete-table --table-name slack-signup-dev

  aws dynamodb delete-table --table-name slack-signup-dev

• Sometimes sls delete fails to clean up. Reasons might be various, but the place to look is the same. Did I tell you to master CloudFormation? Go there, find a stack that failed to delete, find the reason, fix, and delete the stack.

  有时sls delete无法清理。 原因可能千差万别，但外观相同。 我告诉过您掌握CloudFormation吗？ 到那里，找到无法删除的堆栈，找到原因，修复并删除堆栈。

Hope this helped you learn something new, find something interesting, or provoked some good thoughts. Please share your thoughts in the comments here, or tweet me @dzimine.

希望这可以帮助您学习新知识，发现有趣事物或激发一些好的想法。 请在此处的评论中分享您的想法，或在推特上给我@dzimine 。

翻译自: https://www.freecodecamp.org/news/building-a-community-sign-up-app-with-serverless-stepfunctions-and-stackstorm-exchange-episode-7c5f0e93dd6/

serverless 构建