原生Serverless与Serverless Express

Question

现在，我正在遵循从无服务器堆栈小组编写的指南。他们正在使用React和许多AWS特性，如lambda和API getaway。为了实践它，我正在用Serverless无堆栈重写一个旧的Express示例。

我还看到了一个库或工具，名为aws-serverless-express。这个库或工具允许您以serverless形式运行您的serverless应用程序。

这将是一个奇怪的问题，但我想知道原生无服务器构建和无服务器表示之间的区别。

Cold start已经有缺点了。我知道这件事。除此之外，无服务器表示的负面或正面是什么？

本机无服务器的负面或正面是什么？

Answer 1

无服务器快递的缺点

1. 这些额外的依赖关系可能导致额外的冷启动时间。
2. 无法对每个路由具有单独的粒度权限(例如，访问S3的一条路由和访问DynamoDB的另一条路由)

优势

1. 少样板
2. 避免CloudFormation堆栈中的资源限制

更多信息：

https://github.com/jeremydaly/lambda-api#why-another-web-framework

https://www.jeremydaly.com/build-serverless-api-serverless-aws-lambda-lambda-api/#comment-19036

Answer 2

什么是‘本土’无服务器可能是辩论，并构成了一些频谱。有一些方法可以利用托管服务，使lambda函数的使用最小化，但是有很多用例需要自定义逻辑，例如与第三方服务集成。

首先，我会问自己，您的现有应用程序是做什么的，以及您的时间投资将有多大，以重构成为尽可能‘无服务器’。如果这是一个纯粹用于学习目的的项目，您可能希望进行完全转换，以最大限度地提高您的学习能力。如果这是一个企业的创收应用程序，这可能是不适当地使用资源的回报。

尽管如此，当前最佳实践无服务器和无服务器快递的使用之间的主要区别是：

• 附加依赖项的存在。这将需要一些额外的时间来解决在运行时1，将需要正确管理在部署时(打包)，并将需要额外的努力，以更新/补丁/审计(安全)。
• 权限粒度-由于所有路由管理都被委托表示，您将无法在基础结构级别上为每个路由设置粒度权限。
• 您将无法在每个路由的基础上设置资源限制。

另一方面：

• 您将避免使用大型云形成模板。
• 利用您现有的工具和速递知识。

虽然它确实取决于应用程序是什么/做什么，但您不太可能注意到单目的lambda函数的冷启动惩罚，而且可能是过早优化的情况。无服务器思维的一部分是关注价值--所以如果是我做的话，我会尽可能少地让应用程序在lambda中运行--使用X射线和CloudWatch 2开始检测路由，然后优化需要它的路由。

从学习的角度来看，如果你选择使用无服务器快递，你可能会错过更多关于服务集成、VTL转换、请求/响应映射等方面的学习机会，如果您采用了更分段的方法，您可能会被忽略。您可以只使用API和DynamoDB构建一些非常酷的东西--甚至无需触摸lambda函数。

这并不是说以这种方式使用express是一件坏事-- AWS本身请注意，这是一种构建无服务器应用程序的有效方法，而3等新特性对此也有帮助。事实上，由AWS发布的[真实世界无服务器应用程序4示例]遵循了单一功能原则，尽管适用于Java而不是表示应用程序。

1

2

3.

4.

Answer 3

最好是尽可能简单地保持无服务器代码，lambda应该只运行您的业务逻辑，这应该只是一个函数。

如上所述，冷启动是无服务器的主要限制因素。

在无服务器上运行express是无用的，因为它运行节点服务器并侦听某个端口，这不是必需的。Lambda并不总是可用的，它在运行时。