Hygraph (GraphCMS) 开发

为什么 Hygraph 是一个不同类型的无头 CMS

Hygraph（前身为 GraphCMS）是唯一一个从头开始围绕 GraphQL 构建的无头 CMS。这不是营销噱头。这意味着您的内容 API 本身是类型化的、可以精确查询的，并且能够将来自多个来源的内容联合到单个统一 API 中。

自 GraphCMS 时代以来，我们一直在 Hygraph 上构建生产应用程序。我们知道它的优势在哪里、劣势在哪里，以及如何设计可扩展的内容模型，而不会陷入维护噩梦。

选择 Hygraph 的原因

原生 GraphQL，而非后期添加

大多数无头 CMS 平台首先提供 REST API，GraphQL 是后来添加的。Hygraph 改变了这一点。每个内容类型、每个关系、每个资源都会自动获得一个完整的类型化 GraphQL 架构。您只查询需要的字段 — 没有过度获取、没有不足获取、没有链接多个 API 调用。

这对性能很重要。单个 Hygraph 查询可以在一次往返中解决嵌套内容、本地化变体和相关条目。用基于 REST 的 CMS 尝试这样做，页面加载前您就会耗尽速率限制。

内容联合

Hygraph 的 Remote Sources 功能让您可以从外部 REST 和 GraphQL API 中提取数据，并将其视为本地内容。来自 Shopify 的产品数据、来自后端的用户配置文件、来自 Stripe 的定价 — 所有这些都可通过一个统一的 GraphQL 端点访问。

我们大量使用此功能来构建应用程序，其中内容编辑器在 Hygraph 中工作，而前端从多个数据源拉取数据，而不知道或不关心数据的来源。

细粒度权限和工作流

Hygraph 附带基于阶段的内容工作流（草稿 → 审核 → 已发布）和针对企业团队实际有效的基于角色的访问控制。内容编辑器看到他们需要的内容。开发者可以锁定架构变更。审核者可以批准而不涉及生产。

我们的 Hygraph 开发方法

不会损坏的内容建模

任何 CMS 项目中最关键的决定在编写单行前端代码之前就会发生：内容模型。如果这个步骤出错，您将在六个月后重构。

我们使用以下原则设计 Hygraph 架构：

• 组件驱动模型 — 内容类型直接映射到前端组件。编辑器从模块化块组装页面，而不是单个页面类型。
• 关系架构 — 我们提前计划一对多、多对多和多态关系。Hygraph 的联合类型让我们创建灵活的内容结构，而无需求助于通用的"包罗万象"字段。
• 从第一天开始本地化 — Hygraph 支持字段级本地化。我们在初始架构设计期间配置这一点，而不是作为后期补救。
• 枚举字段优于自由文本 — 在可能的地方，我们将输入限制为枚举。这可以防止数据质量问题并使过滤变得可预测。

前端集成

我们主要使用 Next.js 和 Astro 构建 Hygraph 驱动的前端。以下是它的典型样子：

Next.js + Hygraph： 我们使用 Next.js App Router 和服务器组件在构建时或请求时查询 Hygraph。GraphQL 查询在服务器端运行，因此您的 API 令牌永远不会进入浏览器。我们使用 Hygraph webhooks 实现 ISR（增量静态再生成）来在内容更改时重新验证特定页面 — 无需完整重建。

Astro + Hygraph： 对于互动性最少的内容丰富的网站，Astro 的静态优先方法与 Hygraph 结合提供了卓越的性能。我们在 .astro 文件中编写 GraphQL 查询，默认发送零 JavaScript，并仅在需要的地方补充交互式组件。

在这两种情况下，我们使用 GraphQL Code Generator 从 Hygraph 的 GraphQL 架构生成 TypeScript 类型。每个查询都是类型安全的。每个组件都确切地知道期望什么数据形状。

Webhook 驱动的工作流

Hygraph webhooks 在内容生命周期事件上触发 — 创建、更新、发布、取消发布、删除。我们将这些接入到：

• Next.js 中的按需 ISR，无需完整部署即可实现即时内容更新
• 内容更改时 Algolia 或 Meilisearch 中的搜索索引更新
• 通过 Slack 或电子邮件的通知管道用于编辑工作流
• 用于全球分布式网站的 CDN 层的缓存失效

预览和草稿模式

编辑者需要在内容上线前看到未发布的内容。我们使用 Hygraph 的草稿阶段实现 Next.js 草稿模式或 Astro 的服务器呈现预览路由。内容编辑在 Hygraph 中点击预览链接，在实际前端上看到他们的更改呈现，并带有可见的"预览"横幅，这样就不会混淆什么是实时的。

与我们合作您将获得什么

发现和架构设计

我们审计您的内容需求、映射内容类型和关系、并设计针对编辑人体工学和查询性能优化的 Hygraph 架构。在开发开始前，您将获得一个文档化的内容模型。

前端构建

Next.js 或 Astro 中的生产就绪前端，与 Hygraph 完全集成。类型安全的 GraphQL 查询、通过 Hygraph 的资源管道优化的图像处理，以及使用您的设计系统构建的响应式布局。

编辑体验设置

自定义侧边栏小部件、配置的阶段和权限、预览环境，以及记录的编辑工作流。您的内容团队获得一个按他们的思维方式工作的 CMS，而不是按开发者的思维方式。

性能优化

我们实现查询批处理、在支持的地方坚持查询、CDN 缓存策略、以及通过 Hygraph 的内置转换和 next/image 或 Astro 的图像组件优化图像。Core Web Vitals 不是事后考虑 — 它们是我们围绕其设计的约束。

部署和基础设施

我们部署到 Vercel、Netlify 或 Cloudflare Pages，使用 CI/CD 管道运行类型检查、针对 Hygraph 架构 lint GraphQL 查询，并防止破坏性变更到达生产环境。

何时 Hygraph 是正确的选择

Hygraph 在以下情况下效果最好：

• 您的团队已经在用 GraphQL 思考或想要
• 您需要联合来自多个外部源的内容
• 多语言内容是核心需求，而不是锦上添花
• 您想要具有基于阶段的发布的细粒度编辑工作流
• 您的前端使用可以高效使用 GraphQL 的现代框架构建

对于简单博客或喜欢 REST 简洁性的网站来说，它不太理想。我们会提前告诉您，如果替代方案更好，我们会建议它们。

我们的 Hygraph 构建背后的技术

每个项目都不同，但我们的 Hygraph 堆栈通常包括前端的 Next.js 或 Astro、用于类型安全的 GraphQL Code Generator、用于托管的 Vercel 或 Netlify，以及在项目需要时用于 monorepo 管理的 Turborepo 等工具。我们使用 urql 或 graphql-request 作为轻量级 GraphQL 客户端 — Apollo 对大多数 CMS 驱动的前端来说太重了。

我们已为营销网站、文档平台、多品牌内容中心和电子商务店铺推出了 Hygraph 项目。这些模式已被证实。工具已成熟。从客户那里获得的反馈是编辑体验始终最好的。