企业官网建设流程全解析

聚合多种数据源：Apollo Server对接REST API与N+1问题消除实战

【免费下载链接】apollo-server🌍 Spec-compliant and production ready JavaScript GraphQL server that lets you develop in a schema-first way. Built for Express, Connect, Hapi, Koa, and more.项目地址: https://gitcode.com/gh_mirrors/ap/apollo-server

Apollo Server 是一款符合规范、面向生产的 JavaScript GraphQL 服务器，支持 schema-first 开发方式，可运行在 Express、Koa、Hapi 等框架上。本文将聚焦两个高频实战问题：如何用 Apollo Server 聚合多种数据源（对接 REST API），以及如何消除拖慢接口的 N+1 查询问题，帮助新手用最短路径构建稳定的聚合层。

为什么选择 Apollo Server 聚合多种数据源？

在真实业务中，数据往往散落在不同地方：用户信息在 SQL 库、电影目录在第三方 REST API、个性化推荐又在另一个微服务里。Apollo Server 的核心价值，就是用一个 GraphQL 接口把这些数据源"缝合"起来——客户端只发一次请求，服务端由各个 resolver 分头去取数。

官方推荐的组织方式是：为每一种数据源写一个独立的类，把取数逻辑封装在类里，resolver 只负责调用类的方法。这样代码干净、好测试，也方便统一加缓存和错误处理（详见 fetching-data.mdx）。

第一步：用 RESTDataSource 子类封装 REST API 请求

对接 REST API 时，直接使用官方维护的@apollo/datasource-rest包中的RESTDataSource基类。你只需要声明baseURL，然后为每个端点写一个取数方法：

import { RESTDataSource } from '@apollo/datasource-rest'; class MoviesAPI extends RESTDataSource { override baseURL = 'https://movies-api.example.com/'; async getMovie(id: string) { return this.get<Movie>(`movies/${encodeURIComponent(id)}`); } }

要点提示：

• 内置的get/post/put/patch/delete方法会自动解析 JSON、附带查询参数；
• 用encodeURIComponent编码 URL 路径，防止注入；
• 可覆写willSendRequest为所有请求统一加鉴权头或 API key。

第二步：在 context 函数中按请求注入数据源

RESTDataSource内部带有请求级缓存，因此每个请求必须创建新实例（数据库连接池这类长生命周期资源则相反，可以复用）。在context函数里完成注入，并顺手把服务端的共享cache传进去：

const { url } = await startStandaloneServer(server, { context: async () => { const { cache } = server; return { dataSources: { moviesAPI: new MoviesAPI({ cache }), }, }; }, });

resolver 里即可通过contextValue取用：

const resolvers = { Query: { movie: (_, { id }, { dataSources }) => dataSources.moviesAPI.getMovie(id), }, };

⚠️ 常见踩坑：如果全局复用同一个数据源实例，响应会被错误地缓存到"其他请求"里——这正是要求按请求新建实例的原因。更多细节见 fetching-rest.mdx 与 context.mdx。

N+1 问题：为什么 10 篇文章要发 11 次请求？

看这条查询：取 10 篇文章，每篇都要作者名。

query GetPosts { posts { body author { name } } }

朴素实现下，GraphQL 会为每个post触发一次作者查询：1 次取文章列表 + 10 次取作者 =11 次 HTTP 请求，且彼此串行等待。这就是著名的 N+1 问题，是 GraphQL 层 REST 时接口变慢的头号元凶。

双层缓存实战：如何消除 N+1 冗余请求

RESTDataSource天生自带两层缓存，多数 N+1 场景不用手写批处理就能解决：

第一层缓存：并发 GET 请求自动去重

同一请求内，多个 resolver 打到相同 URL的GET（和HEAD）请求，会被自动合并：第一次请求发出后，后续相同请求直接等待并复用结果，不再真正发第二次 HTTP 请求。

举例：10 篇文章里有 3 篇是同一作者，原本要发 10 次作者查询，去重后只需 3 次（每个作者 1 次），N+1 立即退化成 N+K。

第二层缓存：按 HTTP 缓存头与 TTL 存储响应

如果 REST 端点返回了cache-control等标准缓存头，RESTDataSource会按 TTL 规则把响应体存入缓存；你也可以通过cacheOptionsFor方法自定义 TTL。把多个数据源指向同一个cache实例（如服务端的默认缓存，或生产环境的多实例 Redis），还能让缓存跨数据源、甚至跨服务实例共享。

📌 效果：重复请求秒回缓存，数据库与下游 REST API 的压力显著下降。外部缓存后端的配置方法见 cache-backends.mdx。

进阶优化：用 DataLoader 为 REST API 批量取数

去重解决"重复"，但不同 key的 N+1（10 个不同作者）仍需逐次请求。此时可以在数据源内部引入DataLoader：把同一事件循环 tick 内的多次load合并成一次批量请求（例如?ids=1,2,3）。

官方建议：批处理只用于无法被缓存的数据，能缓存的优先走缓存路线——因为批量响应往往无法按单个资源命中缓存（详见 fetching-data.mdx 的 Batching and caching 一节）。

启动后在 Apollo Sandbox 验证数据源

startStandaloneServer启动后，浏览器打开返回的地址即可进入内置的 Apollo Sandbox：左侧浏览 schema 文档，右侧编写查询并实时查看响应。这是验证聚合结果是否正确、观察接口耗时的最快方式。

生产环境下也可以直接对服务端点发送 POST 请求做冒烟测试：

延伸阅读：核心文档与源码路径

总结：用RESTDataSource子类封装每个 REST API、在context中按请求注入实例、利用内建的去重与 TTL 缓存消除 N+1——掌握这套组合拳，你的 Apollo Server 就能稳定聚合任意多种数据源。

【免费下载链接】apollo-server🌍 Spec-compliant and production ready JavaScript GraphQL server that lets you develop in a schema-first way. Built for Express, Connect, Hapi, Koa, and more.项目地址: https://gitcode.com/gh_mirrors/ap/apollo-server