Gatsby Drupal 数据源基准测试站点深度解析从 gatsby-source-drupal 到构建性能验证【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址: https://gitcode.com/gh_mirrors/ga/gatsby导读本文围绕 Gatsby 仓库中的 Drupal Benchmark 基准测试站点展开该站点是一个专门用于衡量「从 Drupal 作为数据源进行构建」性能的可运行示例。通过完整阅读本文你将掌握基准测试站点的目录结构与工作流程、gatsby-source-drupal插件与 GraphQL 数据查询的配置方式、用 Layout 组件切换模拟多页面代码变更的测试手法以及如何通过 Drupal JSON:API 数据更新脚本驱动增量构建的验证方法。基准测试站点的设计目标根据 benchmarks/source-drupal/README.md 的说明该基准测试的核心前提是This benchmark requires space on Drupal and will source its data from there while running the benchmark.也就是说它不是一个自包含的静态示例——它要求你先在一个真实的 Drupal 实例上准备好空间与数据构建过程会实时从 Drupal 拉取内容。其数据模型非常简单查询 Drupal 中文章的标题title、正文body与封面图cover image并为每一篇文章生成一个页面把这些内容以 Articles文章的形式渲染出来。从源码结构看这个基准测试站在 Gatsby 层面只做三件事通过gatsby-source-drupal从 Drupal 获取node__article类型的数据节点在createPages中为每篇文章创建一个独立页面首页与文章详情页共用同一个 Layout 组件通过切换 layout_1.js / layout_2.js 模拟「一个共享组件变更影响多个页面」的场景。这一设计使得它既能度量「大量内容从外部 CMS 拉取」时的构建耗时又能度量「共享组件改动导致多页面重建」时的增量构建效率是 Gatsby 性能基准测试体系中针对 Drupal 数据源的专门样例。目录结构与关键文件该基准站点位于仓库的 benchmarks/source-drupal 目录核心文件如下文件作用gatsby-config.js站点元信息与插件装配核心是gatsby-source-drupalgatsby-node.js为文章节点生成 slug 字段并批量创建文章页面src/pages/index.js首页渲染站点标题与全部文章链接列表src/templates/article.js文章详情页模板标题、正文与封面图src/components/layout_1.js共享布局组件Header Asrc/components/layout_2.js共享布局组件Header B用于模拟变更scripts/data-update.ts数据更新入口读取环境变量并触发更新scripts/updater.ts通过 Drupal JSON:API 修改文章标题模拟数据变更package.json基准测试相关的 npm 脚本与依赖声明环境变量与 Drupal 连接配置站点通过 dotenv 按环境加载.env.${NODE_ENV}文件见 gatsby-config.jsrequire(dotenv).config({ path: .env.${process.env.NODE_ENV}, })这意味着开发环境读取.env.development生产构建读取.env.production。整个基准站点依赖以下环境变量环境变量用途来源文件BENCHMARK_DRUPAL_BASE_URLDrupal 站点地址传给gatsby-source-drupal的baseUrlgatsby-config.jsBENCHMARK_DRUPAL_USERNAME用于 JSON:API 认证的用户名scripts/data-update.tsBENCHMARK_DRUPAL_PASSWORD用于 JSON:API 认证的密码scripts/data-update.tsBENCHMARK_REPORTING_URL置为true时构建结束会上报基准数据package.json 的build:send脚本在 gatsby-config.js 中gatsby-source-drupal的配置如下{ resolve: gatsby-source-drupal, options: { baseUrl: process.env.BENCHMARK_DRUPAL_BASE_URL, // Auth needed for POST }, }注意源码中的注释用户名/密码认证是为POST/PATCH 写操作准备的也就是data-update脚本而构建时拉取数据并不需要。因此若只做纯构建基准测试只需配置BENCHMARK_DRUPAL_BASE_URL若要运行数据更新脚本则还需配置用户名与密码。插件装配与站点元信息gatsby-config.js 中共装配了四个插件分工清晰module.exports { siteMetadata: { siteTitle: Gatsby Drupal 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-drupal, options: { /* ... */ } }, ], }gatsby-plugin-benchmark-reporting基准数据上报插件与build:send脚本配套把构建性能指标发送到基准测试服务端gatsby-plugin-sharp / gatsby-transformer-sharp处理图片处理与转换为 Drupal 的封面图生成响应式/优化后的派生节点childImageSharpgatsby-source-filesystem以src/pages/为内容目录保证页面组件被正确收集gatsby-source-drupal核心数据源负责从 Drupal JSON:API 拉取内容。该配置体现了基准测试的两个衡量维度外部 CMS 数据拉取gatsby-source-drupal与本地图片处理流水线Sharp都会显著影响构建耗时二者叠加构成贴近真实站点的负载。从 Drupal 节点到页面gatsby-node.js 的两段式流程gatsby-node.js 实现了两个 API完整呈现了「数据节点 → slug → 页面」的标准链路。onCreateNode为文章生成 slugconst kebabCase require(lodash.kebabcase) exports.onCreateNode ({ actions, node }) { const { createNodeField } actions if (node.internal.type node__article) { createNodeField({ node, name: slug, value: kebabCase(node.title) }) } }只有当节点类型为node__article即 Drupal 的 Article 内容类型经gatsby-source-drupal映射而来时才用 lodash.kebabcase 将标题转换为 kebab-case 形式的 slug。这里体现了 Gatsby 的字段扩展机制createNodeField写入的fields.slug会与节点一起进入 GraphQL 层供后续查询使用。createPages批量创建文章页面exports.createPages async ({ actions, graphql, reporter }) { const { createPage } actions const result await graphql( { articles: allNodeArticle { nodes { fields { slug } } } } ) if (result.errors) { reporter.panicOnBuild(result.errors) } result.data.articles.nodes.map(article { createPage({ path: article.fields.slug, component: require.resolve(./src/templates/article.js), context: { slug: article.fields.slug }, }) }) }流程要点通过allNodeArticle查询出所有文章的fields.slug若 GraphQL 查询报错调用reporter.panicOnBuild使构建失败并输出错误——这是构建期失败的标准做法对每篇文章调用createPage页面路径即 slug模板指向src/templates/article.js并把 slug 放入context。context.slug会被注入到模板的 GraphQL 查询变量中详见下文 article.js 的query($slug: String!)这是 Gatsby 把页面数据与模板关联起来的经典模式。文章数量越多这里的createPage调用与模板渲染次数就越多——正是基准测试希望放大的负载。首页与文章模板GraphQL 查询的两种形态首页 index.js列表查询src/pages/index.js 渲染站点标题与全部文章链接export const query graphql { site { siteMetadata { siteTitle } } articles: allNodeArticle { nodes { title fields { slug } } } } 这是一个不带变量的静态查询一次拿到站点元信息siteTitle与所有文章的title、fields.slug然后用Link生成指向各文章的导航列表。文章模板 article.js变量查询与图片管线src/templates/article.js 的查询以 slug 为变量export const query graphql query($slug: String!) { article: nodeArticle(fields: { slug: { eq: $slug } }) { title body { processed } relationships { field_image { localFile { childImageSharp { fluid(maxWidth: 960, quality: 90) { ...GatsbyImageSharpFluid_withWebp_tracedSVG } } } } } } } 该查询展示了三个与基准场景直接相关的数据点body.processedDrupal 侧处理后的 HTML 正文模板中通过dangerouslySetInnerHTML渲染模拟真实站点富文本输出relationships.field_image.localFile.childImageSharp.fluidDrupal 图片字段经gatsby-source-drupal下载为本地文件、再由 Sharp 流水线生成fluid变体maxWidth: 960, quality: 90并启用 WebP 与 traced SVG 占位图完整覆盖「外部媒体 → 本地文件 → 图片优化」的重负载链路模板对图片做了容错处理当childImageSharp不存在时显示Image cant be displayed避免构建因缺图失败。渲染时使用gatsby-image的Img组件输出优化图片并提供一个Go back to index page链接返回首页形成完整的站内导航闭环。共享 Layout 与多页面变更模拟README 特别强调的设计意图是文章页与首页共享同一个 Layout 组件可以整体替换以模拟一次影响多个页面的代码变更。仓库中提供了两个等价实现layout_1.js输出Header Alayout_2.js输出Header B。两者结构完全一致唯一的差异是 header 文案。当前首页与文章模板都import Layout from ../components/layout_1当你把两处 import 改为layout_2时所有页面首页 全部文章页的共享布局同时发生变化——这正是增量构建基准测试中「少量代码改动触发大量页面重新生成」的标准载荷。基准测试中验证此类场景时可在修改 import 后执行npm run build观察仅共享组件变更时的重建耗时。数据更新脚本驱动增量构建的「内容变更源」scripts/data-update.ts 与 scripts/updater.ts 共同构成一个用于模拟「Drupal 侧内容变更」的工具目的是为增量构建incremental builds测试制造真实的数据扰动。入口与鉴权参数require(dotenv).config({ path: .env.${process.env.NODE_ENV} }) const username process.env.BENCHMARK_DRUPAL_USERNAME const password process.env.BENCHMARK_DRUPAL_PASSWORD const server process.env.BENCHMARK_DRUPAL_BASE_URL update(username, password, server)入口脚本只做三件事加载环境变量、读取用户名/密码/站点地址、调用update()。如果三者缺失update会打印You must pass username, password and server并直接返回见 updater.ts。JSON:API 数据变更流程updater.ts 的核心逻辑分两步const getFirstArticle async (server: string): PromiseIArticle { const url ${server}/jsonapi/node/article?page[limit]1sortcreated const response await fetch(url) const body await response.json() return body.data[0] }第一步先查询「创建时间最早的一篇文章」sortcreatedpage[limit]1第二步对它发起 PATCH 请求修改标题const updateTitle (title: string): string ${title.substring(0, title.lastIndexOf( ))} ${faker.lorem.word()}updateTitle会去掉标题的最后一个单词并用 faker 生成的随机单词替换它——这样每次运行都能产生确定可观察、又不破坏数据结构的标题变化。PATCH 请求本身使用 Drupal JSON:API 规范const response await fetch(url, { method: PATCH, headers: { Content-Type: application/vnd.apijson, Authorization: Basic ${Buffer.from(${username}:${password}).toString(base64)}, }, body: JSON.stringify({ data: { type: node--article, id: article.id, attributes: { title: updateTitle(article.attributes.title) }, }, }), })这里使用了HTTP Basic 认证Authorization: Basic base64(username:password)与 JSON:API 媒体类型application/vnd.apijson请求体结构符合 JSON:API 的 resource object 规范typeidattributes。这也印证了 gatsby-config.js 中「Auth needed for POST」注释的含义——写操作需要凭据而构建拉取数据不需要。npm 脚本与基准测试运行流程package.json 定义了完整的操作入口脚本命令用途buildgatsby build常规生产构建build:sendcross-env BENCHMARK_REPORTING_URLtrue gatsby build构建并上报基准数据cleangatsby clean清理缓存data-updatets-node scripts/data-update.ts修改 Drupal 文章标题模拟内容变更developgatsby develop开发模式startnpm run develop开发模式别名servegatsby serve预览生产构建产物依赖方面该基准站点固定在 Gatsby v3 生态gatsby ^3.5.1、gatsby-source-drupal ^4.7.2、gatsby-image ^3.5.0配合react ^17.0.2工具链使用ts-nodetypescript ^4.2.4运行数据脚本cross-env用于跨平台设置环境变量。对应的 TypeScript 编译配置见 tsconfig.jsontarget ES2018、strict 模式、commonjs 模块。一个典型的基准测试循环如下准备 Drupal 实例与内容设置BENCHMARK_DRUPAL_BASE_URL如需运行数据脚本再设置BENCHMARK_DRUPAL_USERNAME/BENCHMARK_DRUPAL_PASSWORD执行npm run build或带上报的npm run build:send得到首轮构建基线执行npm run contenteditable="false">【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址: https://gitcode.com/gh_mirrors/ga/gatsby创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Gatsby Drupal 数据源基准测试站点深度解析：从 gatsby-source-drupal 到构建性能验证
Gatsby Drupal 数据源基准测试站点深度解析从 gatsby-source-drupal 到构建性能验证【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址: https://gitcode.com/gh_mirrors/ga/gatsby导读本文围绕 Gatsby 仓库中的 Drupal Benchmark 基准测试站点展开该站点是一个专门用于衡量「从 Drupal 作为数据源进行构建」性能的可运行示例。通过完整阅读本文你将掌握基准测试站点的目录结构与工作流程、gatsby-source-drupal插件与 GraphQL 数据查询的配置方式、用 Layout 组件切换模拟多页面代码变更的测试手法以及如何通过 Drupal JSON:API 数据更新脚本驱动增量构建的验证方法。基准测试站点的设计目标根据 benchmarks/source-drupal/README.md 的说明该基准测试的核心前提是This benchmark requires space on Drupal and will source its data from there while running the benchmark.也就是说它不是一个自包含的静态示例——它要求你先在一个真实的 Drupal 实例上准备好空间与数据构建过程会实时从 Drupal 拉取内容。其数据模型非常简单查询 Drupal 中文章的标题title、正文body与封面图cover image并为每一篇文章生成一个页面把这些内容以 Articles文章的形式渲染出来。从源码结构看这个基准测试站在 Gatsby 层面只做三件事通过gatsby-source-drupal从 Drupal 获取node__article类型的数据节点在createPages中为每篇文章创建一个独立页面首页与文章详情页共用同一个 Layout 组件通过切换 layout_1.js / layout_2.js 模拟「一个共享组件变更影响多个页面」的场景。这一设计使得它既能度量「大量内容从外部 CMS 拉取」时的构建耗时又能度量「共享组件改动导致多页面重建」时的增量构建效率是 Gatsby 性能基准测试体系中针对 Drupal 数据源的专门样例。目录结构与关键文件该基准站点位于仓库的 benchmarks/source-drupal 目录核心文件如下文件作用gatsby-config.js站点元信息与插件装配核心是gatsby-source-drupalgatsby-node.js为文章节点生成 slug 字段并批量创建文章页面src/pages/index.js首页渲染站点标题与全部文章链接列表src/templates/article.js文章详情页模板标题、正文与封面图src/components/layout_1.js共享布局组件Header Asrc/components/layout_2.js共享布局组件Header B用于模拟变更scripts/data-update.ts数据更新入口读取环境变量并触发更新scripts/updater.ts通过 Drupal JSON:API 修改文章标题模拟数据变更package.json基准测试相关的 npm 脚本与依赖声明环境变量与 Drupal 连接配置站点通过 dotenv 按环境加载.env.${NODE_ENV}文件见 gatsby-config.jsrequire(dotenv).config({ path: .env.${process.env.NODE_ENV}, })这意味着开发环境读取.env.development生产构建读取.env.production。整个基准站点依赖以下环境变量环境变量用途来源文件BENCHMARK_DRUPAL_BASE_URLDrupal 站点地址传给gatsby-source-drupal的baseUrlgatsby-config.jsBENCHMARK_DRUPAL_USERNAME用于 JSON:API 认证的用户名scripts/data-update.tsBENCHMARK_DRUPAL_PASSWORD用于 JSON:API 认证的密码scripts/data-update.tsBENCHMARK_REPORTING_URL置为true时构建结束会上报基准数据package.json 的build:send脚本在 gatsby-config.js 中gatsby-source-drupal的配置如下{ resolve: gatsby-source-drupal, options: { baseUrl: process.env.BENCHMARK_DRUPAL_BASE_URL, // Auth needed for POST }, }注意源码中的注释用户名/密码认证是为POST/PATCH 写操作准备的也就是data-update脚本而构建时拉取数据并不需要。因此若只做纯构建基准测试只需配置BENCHMARK_DRUPAL_BASE_URL若要运行数据更新脚本则还需配置用户名与密码。插件装配与站点元信息gatsby-config.js 中共装配了四个插件分工清晰module.exports { siteMetadata: { siteTitle: Gatsby Drupal 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-drupal, options: { /* ... */ } }, ], }gatsby-plugin-benchmark-reporting基准数据上报插件与build:send脚本配套把构建性能指标发送到基准测试服务端gatsby-plugin-sharp / gatsby-transformer-sharp处理图片处理与转换为 Drupal 的封面图生成响应式/优化后的派生节点childImageSharpgatsby-source-filesystem以src/pages/为内容目录保证页面组件被正确收集gatsby-source-drupal核心数据源负责从 Drupal JSON:API 拉取内容。该配置体现了基准测试的两个衡量维度外部 CMS 数据拉取gatsby-source-drupal与本地图片处理流水线Sharp都会显著影响构建耗时二者叠加构成贴近真实站点的负载。从 Drupal 节点到页面gatsby-node.js 的两段式流程gatsby-node.js 实现了两个 API完整呈现了「数据节点 → slug → 页面」的标准链路。onCreateNode为文章生成 slugconst kebabCase require(lodash.kebabcase) exports.onCreateNode ({ actions, node }) { const { createNodeField } actions if (node.internal.type node__article) { createNodeField({ node, name: slug, value: kebabCase(node.title) }) } }只有当节点类型为node__article即 Drupal 的 Article 内容类型经gatsby-source-drupal映射而来时才用 lodash.kebabcase 将标题转换为 kebab-case 形式的 slug。这里体现了 Gatsby 的字段扩展机制createNodeField写入的fields.slug会与节点一起进入 GraphQL 层供后续查询使用。createPages批量创建文章页面exports.createPages async ({ actions, graphql, reporter }) { const { createPage } actions const result await graphql( { articles: allNodeArticle { nodes { fields { slug } } } } ) if (result.errors) { reporter.panicOnBuild(result.errors) } result.data.articles.nodes.map(article { createPage({ path: article.fields.slug, component: require.resolve(./src/templates/article.js), context: { slug: article.fields.slug }, }) }) }流程要点通过allNodeArticle查询出所有文章的fields.slug若 GraphQL 查询报错调用reporter.panicOnBuild使构建失败并输出错误——这是构建期失败的标准做法对每篇文章调用createPage页面路径即 slug模板指向src/templates/article.js并把 slug 放入context。context.slug会被注入到模板的 GraphQL 查询变量中详见下文 article.js 的query($slug: String!)这是 Gatsby 把页面数据与模板关联起来的经典模式。文章数量越多这里的createPage调用与模板渲染次数就越多——正是基准测试希望放大的负载。首页与文章模板GraphQL 查询的两种形态首页 index.js列表查询src/pages/index.js 渲染站点标题与全部文章链接export const query graphql { site { siteMetadata { siteTitle } } articles: allNodeArticle { nodes { title fields { slug } } } } 这是一个不带变量的静态查询一次拿到站点元信息siteTitle与所有文章的title、fields.slug然后用Link生成指向各文章的导航列表。文章模板 article.js变量查询与图片管线src/templates/article.js 的查询以 slug 为变量export const query graphql query($slug: String!) { article: nodeArticle(fields: { slug: { eq: $slug } }) { title body { processed } relationships { field_image { localFile { childImageSharp { fluid(maxWidth: 960, quality: 90) { ...GatsbyImageSharpFluid_withWebp_tracedSVG } } } } } } } 该查询展示了三个与基准场景直接相关的数据点body.processedDrupal 侧处理后的 HTML 正文模板中通过dangerouslySetInnerHTML渲染模拟真实站点富文本输出relationships.field_image.localFile.childImageSharp.fluidDrupal 图片字段经gatsby-source-drupal下载为本地文件、再由 Sharp 流水线生成fluid变体maxWidth: 960, quality: 90并启用 WebP 与 traced SVG 占位图完整覆盖「外部媒体 → 本地文件 → 图片优化」的重负载链路模板对图片做了容错处理当childImageSharp不存在时显示Image cant be displayed避免构建因缺图失败。渲染时使用gatsby-image的Img组件输出优化图片并提供一个Go back to index page链接返回首页形成完整的站内导航闭环。共享 Layout 与多页面变更模拟README 特别强调的设计意图是文章页与首页共享同一个 Layout 组件可以整体替换以模拟一次影响多个页面的代码变更。仓库中提供了两个等价实现layout_1.js输出Header Alayout_2.js输出Header B。两者结构完全一致唯一的差异是 header 文案。当前首页与文章模板都import Layout from ../components/layout_1当你把两处 import 改为layout_2时所有页面首页 全部文章页的共享布局同时发生变化——这正是增量构建基准测试中「少量代码改动触发大量页面重新生成」的标准载荷。基准测试中验证此类场景时可在修改 import 后执行npm run build观察仅共享组件变更时的重建耗时。数据更新脚本驱动增量构建的「内容变更源」scripts/data-update.ts 与 scripts/updater.ts 共同构成一个用于模拟「Drupal 侧内容变更」的工具目的是为增量构建incremental builds测试制造真实的数据扰动。入口与鉴权参数require(dotenv).config({ path: .env.${process.env.NODE_ENV} }) const username process.env.BENCHMARK_DRUPAL_USERNAME const password process.env.BENCHMARK_DRUPAL_PASSWORD const server process.env.BENCHMARK_DRUPAL_BASE_URL update(username, password, server)入口脚本只做三件事加载环境变量、读取用户名/密码/站点地址、调用update()。如果三者缺失update会打印You must pass username, password and server并直接返回见 updater.ts。JSON:API 数据变更流程updater.ts 的核心逻辑分两步const getFirstArticle async (server: string): PromiseIArticle { const url ${server}/jsonapi/node/article?page[limit]1sortcreated const response await fetch(url) const body await response.json() return body.data[0] }第一步先查询「创建时间最早的一篇文章」sortcreatedpage[limit]1第二步对它发起 PATCH 请求修改标题const updateTitle (title: string): string ${title.substring(0, title.lastIndexOf( ))} ${faker.lorem.word()}updateTitle会去掉标题的最后一个单词并用 faker 生成的随机单词替换它——这样每次运行都能产生确定可观察、又不破坏数据结构的标题变化。PATCH 请求本身使用 Drupal JSON:API 规范const response await fetch(url, { method: PATCH, headers: { Content-Type: application/vnd.apijson, Authorization: Basic ${Buffer.from(${username}:${password}).toString(base64)}, }, body: JSON.stringify({ data: { type: node--article, id: article.id, attributes: { title: updateTitle(article.attributes.title) }, }, }), })这里使用了HTTP Basic 认证Authorization: Basic base64(username:password)与 JSON:API 媒体类型application/vnd.apijson请求体结构符合 JSON:API 的 resource object 规范typeidattributes。这也印证了 gatsby-config.js 中「Auth needed for POST」注释的含义——写操作需要凭据而构建拉取数据不需要。npm 脚本与基准测试运行流程package.json 定义了完整的操作入口脚本命令用途buildgatsby build常规生产构建build:sendcross-env BENCHMARK_REPORTING_URLtrue gatsby build构建并上报基准数据cleangatsby clean清理缓存data-updatets-node scripts/data-update.ts修改 Drupal 文章标题模拟内容变更developgatsby develop开发模式startnpm run develop开发模式别名servegatsby serve预览生产构建产物依赖方面该基准站点固定在 Gatsby v3 生态gatsby ^3.5.1、gatsby-source-drupal ^4.7.2、gatsby-image ^3.5.0配合react ^17.0.2工具链使用ts-nodetypescript ^4.2.4运行数据脚本cross-env用于跨平台设置环境变量。对应的 TypeScript 编译配置见 tsconfig.jsontarget ES2018、strict 模式、commonjs 模块。一个典型的基准测试循环如下准备 Drupal 实例与内容设置BENCHMARK_DRUPAL_BASE_URL如需运行数据脚本再设置BENCHMARK_DRUPAL_USERNAME/BENCHMARK_DRUPAL_PASSWORD执行npm run build或带上报的npm run build:send得到首轮构建基线执行npm run contenteditable="false">【免费下载链接】gatsbyReact-based framework with performance, scalability, and security built in.项目地址: https://gitcode.com/gh_mirrors/ga/gatsby创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考