我正在创建一个MVP(最小可行产品(，该MVP使用NodeJS服务器使用Express用于REST API和socket.io连接聊天功能。
我关注的不是成本或可扩展性，而是关于设置时间/维护，而是MVP。无服务器或无服务器会花费更少的时间来设置/维护AWS吗？
无服务器是一个不错的选择，是要设置一个简单的REST API应用程序。使用Express也是一个不错的选择。
API网关和无服务器现在也支持WebSockets，因此创建WebSocket应用程序应该很容易。但是，就socket.io而言，您需要在潜水之前进行一些研究。API网关上的WebSocket支持是一个相对较新的概念，在线上没有太多资源。一开始，与兰伯达的结合可能很难掌握。至于socket.io甚至更少。
我个人建议您为您的MVP运行一个运行socket.io的EC2实例。我认为这会更容易。
有几个原因可以选择无服务器基础架构而不是非服务器。在许多情况下，这些与AWS良好的框架的5个支柱非常紧密地保持一致。无服务器体系结构提供了很好的：
- 可靠性 - 无需猜测能力，可以轻松地水平扩展需求
- 效率 - 大大降低了间歇性和不经常工作量的成本
- 维护 - 不存在
- 可用性 - 高度可用和容错
虽然您提议的项目确实看起来很适合FAAS框架(不频繁且不可预测的工作量，资源需求较低(，但无服务器的缺点，尤其是更复杂且难以测试的体系结构，供应商锁定可以使其具有挑战性快速原型和部署MVP。
您的产品有利于工程折衷在推向市场上的折衷方案，非服务器的方法很可能使您能够以最小的头痛快速发布MVP
有一些无服务器框架可以在AWS lambda函数上使用。根据我的现实经验，每个人都有一些通知：
-
aws amplify(https://docs.amplify.aws(为开发人员提供完整的无堆栈无服务器解决方案。一开始很容易使用。缺点。是随着时间的流逝，部署部分的维护成本更高。当您只需要更改代码时，在AWS上部署堆栈非常慢。它将将所有堆栈文件下载到本地，然后再次上传...
-
无服务器框架(https://www.serverless.com(不那么复杂，富含插件和纳米功能。该框架的缺点是每个代码函数将在lambdas上使用相同。当项目更大时，代码大小更大，因此您的lambda的冷启动较慢。
-
简化框架(https://github.com/simplify-framework/codegen(听起来轻巧但丰富的功能。它允许您在项目中构建CI/CD。这个概念与AWS CDK相似，五月份刚刚发布了几天。您可以使用OpenAPI规格(Swagger Specs(设计API，这些规格将在工具和过程中重复使用并标准化API。尚未仔细地将其锁定。今天您在AWS中，但明天将在您的本地服务器上。
您选择适合解决方案的方法。没有人适合所有。