为啥使用 Apollo GraphQL Sever Express（或其他集成）？

Posted 2023-03-08

【中文标题】为啥使用 Apollo GraphQL Sever Express（或其他集成）？

【英文标题】：Why Express (or other integration) with Apollo GraphQL Sever?为什么使用 Apollo GraphQL Sever Express（或其他集成）？

【发布时间】：2020-08-20 06:25:58

【问题描述】：

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

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

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

【参考方案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 应用程序相比有足够的差异，因此可以使用适当的集成。