为什么使用Apollo GraphQL Sever进行Express(或其他集成)? [英] Why Express (or other integration) with Apollo GraphQL Sever?
问题描述
我正在努力理解Express(或Koa，Hapi等)与Apollo GraphQL服务器集成的附加值.
I am struggling to understand the added value of Express (or Koa, Hapi, etc) integration with Apollo GraphQL server.
I see it can work in stand alone mode very well (an example: https://medium.com/codingthesmartway-com-blog/apollo-server-2-introduction-efc4026f5654).
在哪种情况下，我们应该将其与(或不与)集成一起使用?是什么会导致这个决定?
In which case should we use it with (or without) integration? What should drive this decision?
推荐答案
如果只需要一个GraphQL端点，则通常首选使用独立库(apollo-server)，因为这样可以减少编写的样板(功能类似订阅，文件上传等都可以正常运行，而无需进行其他配置).但是，除了公开单个API端点之外，许多应用程序还需要其他功能.示例包括:
If all you need is a GraphQL endpoint, then using the standalone library (apollo-server) is generally preferred because there will be less boilerplate to write (features like subscriptions, file uploads, etc. just work without additional configuration). However, many applications require additional functionality beyond just exposing a single API endpoint. Examples include:
- Webhooks
- OAuth回调
- 会话管理
- Cookie解析
- CSRF保护
- 监视或记录请求
- 费率限制
- 地理围栏
- 提供静态内容
- 服务器端渲染
- Webhooks
- OAuth callbacks
- Session management
- Cookie parsing
- CSRF protection
- Monitoring or logging requests
- Rate limiting
- Geofencing
- Serving static content
- Server-side rendering
如果您的应用程序需要这种功能，则需要使用Express等HTTP框架，然后使用适当的集成库(即apollo-server-express).
If you need this sort of functionality for your application, then you'll want to utilize an HTTP framework like Express and then use the appropriate integration library (i.e. apollo-server-express).
Apollo Server还包括无服务器解决方案AWS Lambda的集成.例如，如果您希望不使用服务器来获得更好的可伸缩性或消除系统管理员的成本，那么您还需要使用其中一种集成.
Apollo Server also includes integrations for serverless solutions AWS Lambda. If you want to go serverless to, for example, get better scalability or eliminate system admin costs, then you would also need to use one of these integrations.
这篇关于为什么使用Apollo GraphQL Sever进行Express(或其他集成)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
