无头CMS GraphQL连接器

要解决的问题

前端框架直接对接无头 CMS 时，开发者需要反复处理 GraphQL 文档构造、字段选择集、变量定义、缓存失效等细节。WordPress WPGraphQL、Strapi、Contentful 三者的 Schema 差异明显，Apollo Client 与 urql 的用法也各自成体系。内容预览在 ISR 场景下容易失效，Webhook 触发重建的流程往往需要手动编排，这些琐碎逻辑占用了大量工程时间。

核心能力与关键步骤

• 多 CMS 适配：支持 WordPress WPGraphQL、Strapi、Contentful 三类后端，统一以 GraphQL 作为数据接口层。
• 客户端集成：分别处理 Apollo Client 与 urql 的文档创建、查询执行与结果获取。
• 内容预览：在草稿或未发布内容场景下，通过预览模式绕过缓存获取最新数据。
• ISR 缓存失效：内容变更后精准标记相关路由或查询缓存，避免用户看到过期页面。
• Webhook 驱动重建：监听 CMS 发送的 Webhook 事件，自动触发对应页面或数据块重新生成。

GraphQL 文档从根操作类型（Query 对象）开始，逐步定义字段选择集，处理可选与必填变量，并根据 Schema 判断字段返回单对象还是列表。参数可以是枚举类型，例如 Episode 或长度单位 METER、FOOT。

适用边界与注意点

• 仅覆盖 GraphQL 查询层面的连接，不涉及具体 CMS 的鉴权、媒体上传等管理端操作。
• 缓存失效与重建依赖 CMS 正确发送 Webhook，需确认目标平台支持对应事件。
• Apollo Client 与 urql 缓存策略不同，迁移或混用时需要分别处理。
• 预览功能要求 CMS 侧开启对应的预览 API 或环境变量。