为什么使用 Apollo GraphQL Server Express（或其他集成）？答案

【问题标题】：Why Express (or other integration) with Apollo GraphQL Sever?为什么使用 Apollo GraphQL Server Express（或其他集成）？
【发布时间】：2020-11-26 15:51:58
【问题描述】：

我很难理解 Express（或 Koa、Hapi 等）与 Apollo GraphQL 服务器集成的附加价值。

我发现它可以很好地在独立模式下工作（例如：https://medium.com/codingthesmartway-com-blog/apollo-server-2-introduction-efc4026f5654）。

在哪种情况下我们应该使用（或不使用）集成？什么应该推动这个决定？

【问题讨论】：

标签： graphql apollo

【解决方案1】：

如果您只需要一个 GraphQL 端点，那么通常首选使用独立库 (apollo-server)，因为要编写的样板文件更少（订阅、文件上传等功能无需额外配置即可工作）。但是，许多应用程序需要额外的功能，而不仅仅是公开单个 API 端点。示例包括：

网络挂钩
OAuth 回调
会话管理
Cookie 解析
CSRF 保护
监控或记录请求
速率限制
地理围栏
提供静态内容
服务器端渲染

如果您的应用程序需要这种功能，那么您需要使用 Express 等 HTTP 框架，然后使用适当的集成库（即apollo-server-express）。

Apollo Server 还包括无服务器解决方案 AWS Lambda 的集成。例如，如果您想使用无服务器以获得更好的可扩展性或消除系统管理成本，那么您还需要使用其中一种集成。

【讨论】：

谢谢丹尼尔，非常清楚的答案，我明白了。只是一件小事——你的最后一句话。为什么你说集成是部署到 AWS 所必需的？构建一个独立的 Apollo 服务器应该很容易，无需集成，并将其部署到 Lambda 或 Fargate。我理解你了吗？
我没有广泛使用过 Lambda，但我的理解是在运行 HTTP 服务器时不再使用listen，因为实际上没有端口可以监听，并且一切都通过处理函数本身运行.在后台，独立库只是为您设置了一个 Express 服务器，然后当您在服务器实例上调用 listen 时调用 listen。
更重要的一点是，当使用 Azure Functions、Google Cloud Functions 等无服务器解决方案时，架构与常规 Express 应用程序相比有足够的差异，因此可以使用适当的集成。