Gatsby CMS 选型完全指南：从 Headless CMS 对比到 Content Mesh 多系统架构

Gatsby CMS 选型完全指南：从 Headless CMS 对比到 Content Mesh 多系统架构

【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址: https://gitcode.com/gh_mirrors/ga/gatsby

导读：本文以 Gatsby 官方《Choosing Your CMSs》概念文档为骨架，系统讲解中型及大型 Gatsby 站点如何选型 CMS——从"一等集成（first-class integration）""价格分层""专项需求"三个维度缩小候选范围，再到借助 Content Mesh 思路在同一站点内混用多个 CMS 打通内容数据，最后覆盖 Markdown/MDX、JSON/YAML、表格类工具等非 CMS 替代方案。读完你将掌握一套可落地的 CMS 评估框架，并能在gatsby-config.js与gatsby-node.js中实际配置多内容源并建立跨 CMS 的内容关联。

为什么 Gatsby 站点需要一个 Headless CMS

大多数中型和大型 Gatsby 网站，其底层都运行着一个所谓"无头 CMS"（headless CMS）。与传统的"有头"一体化 CMS 不同，Headless CMS 把内容管理与内容展示彻底分离：内容编辑者在前台界面里灵活地创建内容模型（content schema）与相互关联的内容类型（content model），而 Gatsby 则通过 source 插件在构建期把内容拉取为 GraphQL 数据层中的节点，再由 React 组件渲染成静态页面。

这也是为什么"我的 Gatsby 站点该用哪个 CMS？"成为构建者最常问的问题之一——它直接决定了内容编辑者的体验、团队的开发效率以及构建流水线（尤其是预览与增量构建）的顺畅程度。

本仓库中大量 source 插件即为这一架构的实证：gatsby-source-contentful、gatsby-source-drupal、gatsby-source-wordpress、gatsby-source-shopify、gatsby-source-strapi等均位于 packages/ 目录下，它们统一遵循"读取远程内容 → 创建 GraphQL 节点 → 供页面查询"的模式。以gatsby-source-drupal为例，其 README 明确指出它从安装了 JSON:API 模块的 Drupal 8/9 站点拉取数据（含图片），对应的可运行示例见 examples/using-drupal。

三个维度快速圈定候选 CMS

如果你需要的是一个承担全站内容的主 CMS（通用、灵活的内容建模能力），官方建议从以下三个主要因素出发缩小搜索范围：

1. 在 Gatsby 用户中流行、且具备一等 Gatsby 集成（first-class integration）的 CMS
2. 价格点（price point）是否契合预算
3. 是否存在专项需求（specialized requirements）

维度一：一等集成与社区流行度

所谓"一等集成"，指的是该 CMS 的 source 插件完整支持 Gatsby 云（Gatsby Cloud）的核心能力——内容预览（previews）与增量构建（incremental builds），并且其质量得到 Gatsby 团队的认可。判断流行度，则可以查看插件目录中按月度下载量排名的gatsby-source-*系列插件。

截至2021 年 11 月，Gatsby 用户中使用占比超过 1%、且拥有一等集成的 CMS 共有八家：

• 纯 Headless CMS：Contentful、DatoCMS、Prismic、Contentstack、Sanity、Strapi
• 全栈（Full-stack）CMS：Drupal、WordPress
• 电商平台：Shopify

从源码侧可以印证这些"一等集成"并非空谈。gatsby-source-wordpress在 docs/features/preview.md 中完整描述了其预览工作流；gatsby-source-contentful的 README 则提供了Delivery API（cdn.contentful.com）与 Preview API（preview.contentful.com）两套接入方式——这正是支撑"草稿内容预览"这一一等集成能力的底层设计。

维度二：按预算评估价格点

官方给出的价格分层参考如下（注意价格与免费额度会随厂商策略变化，请以各家官网实时信息为准）：

• 个人项目 / 原型（慷慨的免费层）：Contentful、DatoCMS、Prismic、Sanity、Strapi
• 团队 / Pro / Business（约 50–250 美元/月）：Contentful、DatoCMS、Prismic、Sanity、Strapi、Drupal、WordPress
• 企业级（约 1000 美元/月及以上）：Contentful、Contentstack、Sanity、Strapi

可以看到三个档位存在明显交集：Contentful、Sanity、Strapi 覆盖面最广，从免费层直达企业层；Contentstack 与 Drupal、WordPress 则更偏向中高预算或特定部署形态。

维度三：专项需求与团队偏好

除了普适性指标，项目自身的特殊需求与团队习惯往往才是最终拍板的关键。官方观察到的典型倾向包括：

• Contentful：与 Gatsby 搭配使用的最常见 Headless CMS。作为早期玩家，其功能与营收都相当成熟，常被视为"默认选择"。
• Contentstack：喜欢其编辑界面、且拥有企业级预算的团队。
• DatoCMS：担心触碰 Contentful 的模型数量限制、希望以更低价格获得同类能力的团队。
• Drupal：看重开源、可配置性（configurability）或需要自定义代码的团队。
• Prismic：偏爱其内容编辑 UI 的团队。
• Sanity / Strapi：看重开发者友好性，或有本地化部署（on-premise）需求的团队。此外Sanity 往往能带来显著更短的构建时间，对大型站点而言这是非常关键的使用体验因素。
• WordPress：客户或内容团队已经熟悉 WordPress 后台界面的场景。

以本仓库为例，gatsby-source-contentful的配置灵活性可以从其 README 的参数列表中一窥全貌：除必填的spaceId与accessToken外，还支持environment（默认master）、host（切换 Preview API）、downloadLocal（是否下载资源到本地）、localeFilter/contentTypeFilter（按区域或内容类型裁剪节点以降低内存）、enableTags（开启标签功能）、typePrefix（多实例冲突隔离）等十余个选项。这意味着"选型"之后，"调优"同样有章可循——例如在空间很大、只想取单一语言数据时，localeFilter: locale => locale.code === 'de-DE'就能大幅减少 GraphQL 节点数量。

多 CMS 混用：Content Mesh 实践

某些场景下，只用一套 CMS 反而别扭——比如某个 CMS 对站点某一部分非常合适，但对其余部分却差强人意。Gatsby 让"站内不同模块使用不同 CMS"变得很容易，这种架构被称为content mesh（内容网格）思路。

实践中，混用多 CMS 的团队通常遵循同一模式：为网站的某一部分使用专项 CMS，其余部分使用通用 CMS。官方给出的两个最常见示例是：

用 Shopify 做电商、用通用 CMS 做其余部分

Shopify 拥有业内顶尖的电商功能，但其其余界面（例如博客功能）相较其他系统常被诟病。因此许多电商站点的做法是：商店后端用 Shopify，站内其余部分用 Contentful 之类的通用 CMS 支撑。本仓库的 examples/using-shopify 展示了gatsby-source-shopify的接入方式，而其gatsby-config.js完全可以与gatsby-source-contentful并列配置，实现一个站点同时拉取两个内容源。

用 WordPress 做博客、用灵活建模 CMS 做其余部分

WordPress 对内容作者极为友好，拥有业内顶尖的内容撰写体验。因此有些团队把博客部分迁到 Gatsby，其余部分交给支持灵活内容建模的 CMS。Apollo 官方与 Gatsby 官方博客都采用了这一组合。在本仓库中，benchmarks/source-wordpress/gatsby-config.js提供了一个真实的 WordPress 接入样板：

require("dotenv").config({ path: `.env.${process.env.NODE_ENV}`, }) module.exports = { siteMetadata: { siteTitle: `Gatsby WordPress Build Benchmark`, }, plugins: [ `gatsby-plugin-benchmark-reporting`, `gatsby-plugin-sharp`, `gatsby-transformer-sharp`, { resolve: `gatsby-source-filesystem`, options: { name: `pages`, path: `${__dirname}/src/pages/`, }, }, { resolve: `gatsby-source-wordpress`, options: { url: process.env.BENCHMARK_WPGRAPHQL_URL, type: { Post: { limit: process.env.NODE_ENV === `development` ? 50 : false, }, }, }, }, ], }

这个示例同时展示了两个重要实践：用dotenv把敏感凭据（如 GraphQL 地址）收敛进环境变量、以及在开发环境下限制拉取数量（limit: 50）以加快本地开发——同样的手法完全适用于多 CMS 场景下的每一个内容源。

多 CMS 下的关键问题：跨系统内容关联

把内容分散到多个系统后，一个核心问题随之而来：某个时刻，一个内容系统往往需要"知道"另一个系统。例如，Contentful 中的一个落地页需要嵌入来自 Shopify 的某个具体商品 SKU 信息，或嵌入 WordPress 中的某篇博客文章。

官方推荐的最简单的跨 CMS 关联方式，是让其中一个 CMS 存储另一个 CMS 中内容的唯一 ID。具体做法是：在 Contentful 的相关内容模型中，用一个数组字段存储 WordPress 博客文章的 ID 列表，然后在gatsby-node.js中通过相应的 GraphQL 查询拉取正确数据并注入页面上下文。

上图来自 Gatsbyjs.com 官方站点的 Contentful 配置（电商用例页，时间约为 2020 年 1 月）：内容模型名为Use Case Landing Page，字段名为Blog Posts，数组内的每一项都是来自 WordPress 的博客文章唯一 ID。

这种"存 ID、查数据"的模式与 Gatsby 的数据层设计天然契合：多个 source 插件产生的节点统一汇入同一个 GraphQL schema，因此你完全可以在一次查询中跨内容源取数——先在gatsby-node.js的createPages中查询 Contentful 落地页拿到blogPostsID 数组，再查询 WordPress 的wpPost节点，最终把两者的数据一起作为context传给页面模板。

非 CMS 的内容方案

并非所有内容都必须放进 CMS。对于以下场景，官方明确列出了几类"非 CMS"的内容组织与管理方案，它们同样工作良好：

• Markdown 与 MDX：文档站和小型开发者站点的常见选择。对开发者而言它们是天然的内容撰写格式，且 MDX 允许在内容中直接嵌入 React 组件。可参考本仓库的 examples/using-markdown-pages 与 examples/using-mdx。此外，若希望为非技术编辑者提供图形化界面，可考虑 Forestry.io 或 Netlify CMS 这类基于 Git 的 CMS——它们本质是给 Markdown 工作流套上一层 UI。
• JSON 或 YAML：适合层级化数据（例如站点导航树），尤其是底层内容已经用 Markdown 存储的情况。仓库中的 examples/using-gatsby-with-json-yaml 演示了如何在 Gatsby 中直接消费这两种格式。
• 网页版电子表格：如Airtable或Google Sheets，适合表格型数据。Impossible Foods 曾用 Airtable 支撑其门店定位器，ProPublica 也曾把 Google Sheets 当作交互式数据新闻图表的"数据库"。
• 领域专用解决方案：针对网站的特定板块采用专门服务，例如招聘页（Careers）直接对接 Greenhouse 或 Lever 的招聘数据——本仓库的 examples/creating-source-plugins 展示了如何为这类专用数据源编写自定义 source 插件，从而让非标准数据源也能融入 Gatsby 的 GraphQL 数据层。

总结：一套可复用的选型决策流程

综合官方指南与本仓库的源码实证，可以沉淀出如下选型决策流程：

1. 先定主 CMS：用"一等集成 × 流行度 × 价格 × 专项需求"四把尺子，从 Contentful、DatoCMS、Prismic、Contentstack、Sanity、Strapi、Drupal、WordPress 中圈出 2–3 个候选，用各自的 source 插件（见 packages/ 下gatsby-source-*系列）分别搭建最小可运行示例做对比验证。
2. 再拆内容域：评估站点的电商、博客、招聘等板块是否适合交给专项系统。若适合，就按 Content Mesh 思路引入第二个内容源，并在gatsby-config.js中并列配置多个 source 插件。
3. 打通跨系统关联：对需要互相引用的内容，采用"一个系统存另一个系统的唯一 ID"方案，在gatsby-node.js中完成跨源查询与页面数据组装。
4. 考虑非 CMS 替代：文档、配置型数据、表格数据等场景，优先评估 Markdown/MDX、JSON/YAML、Airtable/Google Sheets 等轻量方案，避免为简单内容引入过重的 CMS 运维成本。

无论最终选择哪套组合，Gatsby 的 source 插件体系（gatsby-source-contentful、gatsby-source-drupal、gatsby-source-wordpress、gatsby-source-shopify等）都保证了"内容源可插拔、可混合、可替换"——这正是 Headless 架构与 Content Mesh 思想的真正价值所在。

【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址: https://gitcode.com/gh_mirrors/ga/gatsby