GraphQL 高级概念与架构设计模式有哪些核心要点

联合类型和接口类型有什么区别，分别适合什么场景

GraphQL 的联合类型（Union）和接口类型（Interface）都用于处理"一个字段可能返回多种类型"的情况，但设计意图和适用场景不同。

接口类型定义了一组共享字段，实现接口的类型必须包含这些字段。适合多个类型有共同特征的场景，比如 Node 接口要求所有实现类型都有 id 和 createdAt，这是 Relay 全局 ID 规范的基础。

graphql
interface Node {
  id: ID!
  createdAt: DateTime!
}

type User implements Node {
  id: ID!
  createdAt: DateTime!
  name: String!
  email: String!
}

联合类型不要求共享字段，各类型可以完全不同。适合搜索等返回结果差异大的场景。

graphql
union SearchResult = User | Post | Comment

选择依据很简单：如果多个类型有公共字段，用接口；如果各类型结构差异大、只是凑在同一个返回里，用联合类型。实际项目中，接口用于抽象公共行为（如分页、审计字段），联合类型用于多态查询结果。

联合类型的 Resolver 需要实现 __resolveType，根据返回对象的特征判断具体类型：

javascript
const resolvers = {
  SearchResult: {
    __resolveType: (obj) => {
      if (obj.email) return 'User';
      if (obj.title) return 'Post';
      if (obj.text) return 'Comment';
      return null;
    }
  }
};

查询时通过内联片段（Inline Fragment）获取各类型的特有字段：

graphql
query Search($query: String!) {
  search(query: $query) {
    ... on User { id name email }
    ... on Post { id title }
    ... on Comment { id text }
  }
}

DataLoader 如何解决 N+1 查询问题

N+1 问题是 GraphQL 性能最典型的坑。查询一个文章列表，每个文章再单独查作者，100 篇文章就产生 101 次数据库查询。

DataLoader 的原理是批处理和缓存。在单次请求内，它把对同一数据源的多次 load 调用收集起来，合并成一次批量查询，结果按原始顺序返回。

javascript
const DataLoader = require('dataloader');

const userLoader = new DataLoader(async (userIds) => {
  const users = await User.findAll({ where: { id: userIds } });
  return userIds.map(id => users.find(u => u.id === id));
});

在 Resolver 中使用时，多次调用 load 会自动合并：

javascript
const resolvers = {
  Post: {
    author: (post, _, context) => {
      return context.userLoader.load(post.authorId);
    }
  }
};

关键点在于 DataLoader 实例应该按请求创建，而不是全局单例，否则跨请求的缓存会导致数据不一致。通常在请求上下文中初始化：

javascript
const server = new ApolloServer({
  context: () => ({
    userLoader: new DataLoader(batchGetUsers),
    postLoader: new DataLoader(batchGetPosts)
  })
});

DataLoader 还有 prime 方法可以预填充缓存，适合在父级查询中已经拿到关联数据的场景，避免子 Resolver 重复查询。

GraphQL 订阅的原理和实现方式

订阅（Subscription）是 GraphQL 处理实时数据的机制，底层基于 WebSocket。与 Query 和 Mutation 的请求-响应模式不同，订阅建立持久连接，服务端在数据变化时主动推送。

定义订阅和定义查询一样，只是在 Subscription 类型下声明：

graphql
type Subscription {
  postCreated: Post!
  commentAdded(postId: ID!): Comment!
}

实现上，核心是发布-订阅模式。生产环境推荐用 Redis 作为消息中间件，避免单进程内存 PubSub 的局限性：

javascript
const { RedisPubSub } = require('graphql-redis-subscriptions');

const pubsub = new RedisPubSub({
  connection: { host: 'localhost', port: 6379 }
});

const resolvers = {
  Subscription: {
    postCreated: {
      subscribe: () => pubsub.asyncIterator(['POST_CREATED'])
    }
  },
  Mutation: {
    createPost: async (_, { input }) => {
      const post = await Post.create(input);
      pubsub.publish('POST_CREATED', { postCreated: post });
      return post;
    }
  }
};

带参数的订阅（如 commentAdded(postId: ID!)）需要过滤，只推送匹配的事件。withFilter 工具简化了这个逻辑：

javascript
const { withFilter } = require('graphql-subscriptions');

commentAdded: {
  subscribe: withFilter(
    () => pubsub.asyncIterator(['COMMENT_ADDED']),
    (payload, variables) => {
      return payload.commentAdded.postId === variables.postId;
    }
  )
}

实际部署中要注意 WebSocket 连接的认证（通常在连接握手时验证 token）、连接数控制，以及断线重连策略。

Schema 拆分和联邦架构怎么选

小项目一个 Schema 文件够了，项目大了就需要拆分。两种思路：Schema Stitching 和 Apollo Federation。

Schema 拆分是模块化组织方式，把类型定义按业务域分文件，构建时合并成一个 Schema。这是代码组织层面的拆分，服务仍然是一个：

javascript
const { mergeTypeDefs } = require('@graphql-tools/merge');
const { loadFilesSync } = require('@graphql-tools/load-files');

const typeDefs = mergeTypeDefs(loadFilesSync('./schemas'));

**联邦架构（Federation）**是分布式架构，每个服务独立运行自己的 GraphQL 服务器，通过网关组合对外提供统一 API。适合微服务团队各自迭代：

graphql
# 用户服务
type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
}

# 文章服务扩展 User 类型
extend type User @key(fields: "id") {
  id: ID! @external
  posts: [Post!]!
}

网关通过 @key 指令识别实体，跨服务引用时自动调用引用解析器：

javascript
const resolvers = {
  User: {
    __resolveReference: ({ id }) => User.findById(id)
  }
};

选择依据：如果团队是单体架构但代码量大了，Schema 拆分就够了；如果是多个团队独立部署服务，才需要联邦架构。联邦引入的复杂度不低——网关治理、Schema 演进协调、跨服务调试都是实际挑战，不要为了用而用。

自定义指令怎么用

指令（Directive）是在 Schema 声明中附加行为的机制，比如权限校验、缓存控制、字段转换。常见于 @auth、@cache 这类横切关注点：

graphql
directive @auth(requires: Role = ADMIN) on FIELD_DEFINITION
directive @cache(ttl: Int = 60) on FIELD_DEFINITION

enum Role { USER ADMIN }

Apollo Server 支持指令解析器（Directive Resolver），在字段执行前后插入逻辑：

javascript
directiveResolvers: {
  auth: (next, source, args, context) => {
    if (!context.user || context.user.role !== args.requires) {
      throw new Error('Unauthorized');
    }
    return next();
  },
  cache: async (next, source, args, context) => {
    const key = `cache:${context.requestId}:${JSON.stringify(source)}`;
    const cached = await redis.get(key);
    if (cached) return JSON.parse(cached);
    const result = await next();
    await redis.setex(key, args.ttl, JSON.stringify(result));
    return result;
  }
}

指令的局限是 GraphQL 规范只定义了 @include、@skip、@deprecated 三个内置指令，自定义指令的行为完全依赖服务端实现，客户端无法感知。此外，指令执行顺序在规范中没有定义，多个指令叠加时要注意依赖关系。

CQRS 和事件溯源在 GraphQL 中怎么应用

CQRS（命令查询职责分离）把读和写分成两条路径，适合读写负载差异大的系统。在 GraphQL 中，Query 走读库（通常是优化过的只读副本），Mutation 走写库并通过事件总线同步：

javascript
const resolvers = {
  Query: {
    user: (_, { id }, { readDb }) => readDb.User.findById(id)
  },
  Mutation: {
    createUser: async (_, { input }, { writeDb, eventBus }) => {
      const user = await writeDb.User.create(input);
      await eventBus.publish('USER_CREATED', { user });
      return user;
    }
  }
};

事件溯源（Event Sourcing）不存储当前状态，而是存储所有变更事件，通过回放事件重建状态。和 CQRS 组合使用时，写端存事件，读端通过事件处理器构建物化视图：

javascript
class EventStore {
  async saveEvent(aggregateId, eventType, payload) {
    await Event.create({ aggregateId, eventType, payload, timestamp: new Date() });
  }
  async getEvents(aggregateId) {
    return Event.findAll({ where: { aggregateId }, order: [['timestamp', 'ASC']] });
  }
}

这两种模式的代价是系统复杂度显著增加——事件最终一致性、调试困难、数据迁移复杂。只有在对审计追溯有强需求，或读写 QPS 差距极大时才值得引入。

GraphQL 错误处理有哪些最佳实践

GraphQL 的错误处理和 REST 不同，查询部分失败时仍然返回数据，错误信息放在 errors 数组中。这要求开发者设计错误结构，而不是简单抛异常。

自定义错误类是基础实践，按业务分类错误码：

javascript
class GraphQLError extends Error {
  constructor(message, code, extensions = {}) {
    super(message);
    this.code = code;
    this.extensions = extensions;
  }
}

class ValidationError extends GraphQLError {
  constructor(message, field) {
    super(message, 'VALIDATION_ERROR', { field });
  }
}

formatError 函数统一错误输出格式，生产环境过滤内部细节：

javascript
const formatError = (error) => {
  if (error.originalError instanceof GraphQLError) {
    return { message: error.message, code: error.originalError.code };
  }
  if (process.env.NODE_ENV === 'production') {
    return { message: 'Internal server error', code: 'INTERNAL_ERROR' };
  }
  return error;
};

生产中常见的问题是把业务错误和系统错误混在一起。建议在 Schema 层面把可预期的错误设计成返回类型的一部分（如 type CreateUserResult { user: User error: ValidationError }），而不是抛到 errors 数组，这样客户端可以类型安全地处理。不可预期的系统错误才走 errors 数组。

GraphQL 测试策略怎么设计

Resolver 单元测试关注单个字段的逻辑，用 mock 隔离数据层：

javascript
describe('Query.user', () => {
  it('should return user by id', async () => {
    User.findById = jest.fn().mockResolvedValue({ id: '1', name: 'John' });
    const result = await resolvers.Query.user(null, { id: '1' });
    expect(result.name).toBe('John');
  });
});

集成测试验证整个查询流程，用 createTestClient 对 Apollo Server 发送实际 GraphQL 请求：

javascript
const { query } = createTestClient(server);

const { data, errors } = await query({
  query: 'query { users { id name } }'
});
expect(errors).toBeUndefined();
expect(data.users).toBeDefined();

测试优先级：Resolver 逻辑单元测试 > 权限校验测试 > 全链路集成测试。订阅测试需要模拟 PubSub 事件触发，验证推送内容和过滤逻辑。自定义指令的测试通过 @auth 标记的字段验证未授权时是否拒绝访问。

端到端测试可以用真实的 WebSocket 连接验证订阅流程，但这类测试慢且不稳定，少量覆盖关键路径即可。

面试中 GraphQL 架构设计常被追问什么

N+1 问题是最常被追问的点。面试官会问"DataLoader 的批处理窗口怎么控制"、"缓存和批处理分别在什么层面生效"。答案是 DataLoader 在事件循环的一个 tick 内收集 load 调用，下一个 tick 发起批量请求；缓存在请求级别，避免跨请求数据污染。

联邦架构的取舍也是高频问题。面试官关注的是"联邦引入的复杂度是否值得"，回答应该结合团队规模和服务边界。如果只有两三个服务，Schema Stitching 更简单。

订阅的可靠性常被追问断线重连和消息丢失。WebSocket 断开后客户端需要用最后收到的事件 ID 重连，服务端需要支持从指定事件 ID 开始回放。Redis PubSub 不持久化消息，需要配合 Redis Stream 或消息队列做兜底。

Schema 演进是高级问题。面试官期望你了解字段弃用策略（@deprecated + 保持兼容期）、输入类型的非空字段只能加不能删、以及联邦场景下跨服务 Schema 变更的协调方式。