这不是盖茨比目前所做的事情，而是人们所要求的。 第2版​​中已经进行了一些

@ m-allanson是否存在有关如何处理此问题的讨论/问题？ 在您列出的链接中没有看到它。 我很好奇听到有关如何在主机（如Netlify）上处理该问题的对话，以及使用诸如Wordpress / Drupal之类的CMS（目前在构建过程中需要大量HTTP请求）的对话。

AFAIK您将无法在netlify上使用增量版本，因为.cache和public目录在版本之间没有保留，因此它将始终执行干净的版本

很高兴知道。 我正在提出很多思想不周的想法。 因此，即使我们可以消除对HTTP请求的需求，我们仍然需要确保构建工具可以引用.cache和public目录，从而消除了许多降低条目准入条件的主机。

增量构建的另一个用例是当您有一个很大的站点要分批构建时。 一次构建约5k页时，出现“堆满内存错误”。

我们计划将网站扩大到很大，因此我们正在大规模测试盖茨比。 我们尝试执行类似path: './src/pages/${subPath}', ，其中subPath是process.argv[3] 。 当我们使用gatsby develop托管网站的某些部分时，这很好用。 当将gatsby build用于5k +页面站点时，它还可以避免内存堆的问题。 要使其真正成为解决方案，可能取决于在公用文件夹内指定输出子目录的能力： https :

如果使用另一种方法来实现相同的目标该怎么办。 我想由你们提出一个想法，看看人们的想法。 因此，假设您有一个5k页的网站。 初始页面将是静态生成的，但是每个页面将具有一个子组件，该子组件将加载在静态内容之上，其内容与从静态json文件读取的内容相同。 这样，如果用户想在一天中更新CMS中的一页，他们就可以进行更新，而该静态json文件将被重新生成并部署到CDN。 然后，您可以将整个站点每天更新一次，作为一个夜间过程。 SEO静态内容可能不是一天中最新的内容，但我认为这没什么大不了的。 它将在每晚过程中更新。

@robertschneiderman我们也遇到了内存问题。 我们接近1500页，但是图像数量却非常疯狂（设计博客）。 我们已经关闭了源映射，并停止了下载图像文件的构建，但是最终不得不编辑build命令来增加分配给节点实例的内存。 通过--max_old_space_size标志。

使我担心此功能的一件事是架构构建。 如果我们没有所有可用于gatsby的帖子来构建模式，那么我们的查询将引发错误。 如果有一种方法可以将模式传递给gatsby，或者至少在构建过程中提供虚拟实体来演示它们可能采用的不同形状，那将非常好。

我正在考虑使用Gatsby为包含5000多个项目的内容站点构建UI，其中大多数相互之间具有相互联系的关系。 数据将来自数据库驱动的CMS。

在标准的API驱动的React网站上使用Gatsby的好处是，我将花费一小部分时间来构建和维护数据API和状态管理系统，以加载并存储远程数据。 （由于我计划将应用程序部署到大小相似的多个站点，因此这似乎是非常宝贵的好处。）

在这种情况下使用Gatsby的不利之处在于，即使对于最无关紧要的内容更新，也需要重新构建整个网站。 忘记添加逗号？ 重建所有5000页！ 谁甚至不知道需要多长时间？ 考虑CMS用户的体验时，这甚至是一个更大的问题-他们习惯于看到更改后将其保存在网站上。 对于盖茨比，我们正在等待（至少）几分钟，直到更改出现。

如果有一种方法可以触发部分页面的构建，那么Gatsby无疑是明确的选择。 但是，在目前，这是一个艰难的过程。

顺便说一句，我一直在努力提高v2大型站点构建的速度。 在最新的v2 beta中-您可能可以在<1:30的时间内建立5000个页面。 将会有更多的速度改进。

@KyleAMathews太神奇了！ 我绝对很期待！ 让我知道您是否要针对图像繁重的博客进行测试

@KyleAMathews 5K很好，但我们需要1M😉

如果我们要分别编译站点的各个部分，可以在build上设置标志，以便gatsby-node仅知道生成指定站点的各个部分。 然后，我们可以重新添加先前生成的静态文件。 只要我们使用基本<a href>而不是<Link to >链接到先前生成的文件，这对我们就可以使用。

我想知道如果在构建时合并到先前的data.json ，是否可以使<Link to>在链接到先前生成的文件时起作用。 此刻正在进一步研究。

我不必担心构建时间，但可以担心需要更新的静态文件数量，我们与Gatsby一起推出了一个大型可视化产品组合，要上传的静态网站超过150 MB
主要是图像。
这使得网站在更新期间约40分钟不可用
重建站点的一部分的可用性绝对是可以提高Gatsby的功能。
我计划将Gatsby用于新网站，但我将使用传统的php CMS将新闻分为静态和动态两部分。

@rbmedia，您可能需要考虑像Netlify这样进行部署切换的主机，以便您的当前站点保持运行，直到准备好新版本为止。

谢谢马特，我会考虑的！
过去我确实使用Drupal建立了一些新闻网站，任何更新都必须在短时间内（不到2分钟）在线。 我很想将来将Gatsby用于此类网站。

关于这个问题有什么消息吗？ 我们计划一个约有10万页的网站，并且增量构建会很棒。

将其他路径设置为默认静态页面文件夹，而不是“ / public”。
运行gatsby build之后，将../public/*复制到默认路径。

iya！

这个问题已经悄无声息。 幽灵般的安静。 👻

我们遇到了很多问题，因此我们目前在闲置30天后就关闭了问题。 从上一次更新到现在已经至少20天了。

如果我们错过了此问题，或者您想使其保持打开状态，请在此处回复。 您也可以添加标签“ not stale”以保持此问题的状态！

感谢您加入盖茨比社区！ 💪💜

我仍然不认为这在盖茨比中是固定的/受支持的。 @TeamGatsby有什么消息吗？

这是一个长期存在的问题，因为如果不认真考虑就很难解决。 @Moocar存在一个问题，至少可以使我们朝正确的方向迈出一步。

Gatsby当前是否跟踪在给定页面上检索到的GraphQL节点？ 如果是这样，似乎可以根据数据更改添加增量重建。 那是工作的一半，不是吗？

另一工作是为源插件提供缓存，并鼓励插件开发人员仅在可能的情况下获取更改的数据。 在许多情况下，这是微不足道的。

@coreyward是的，Gatsby跟踪通过查询返回的每个节点（通过page-dependency-resolver.js ）。 这就是gatsby develop的能力，它仅针对已更改的数据仅重新运行查询。 我们目前不将该信息保存到磁盘，因此尚未用于gatsby build ，但这绝对是计划。

我知道对于我们的团队来说，这将是不批准使用Gatsby进行2019年旗舰网站重建的决定。 我真的希望它可以发布，或者至少在我们开始构建时即将发布。 在整个工作日中，我们支持数百名Web作者来编辑网站的各个部分。 当他们点击保存时，他们非常希望内容会被更新。 对于他们来说，回过头来修复逗号或更改帖子的日期并不少见。

@mattbloomfield我们有更多对此感兴趣的客户，因此我们将其列为优先事项。

我们正在使用gatsby-source-graphql插件在drupal 8后端上实现gatsby，到目前为止，性能还不是问题，在不到30秒的时间内构建了约4000个页面。 我们将在gatsby节点中提取所有数据，而不是运行数千个StaticQuery，并且暂时不进行图像处理。

```
成功运行graphql查询-3.088 s-4008/4008 1311.56查询/秒
成功写出页面数据-0.070 s
成功写出重定向数据-0.001 s
成功构建清单和相关图标-0.117 s
onPostBootstrap成功-0.127 s

信息引导程序完成-15.751 s

成功建立生产JavaScript和CSS包— 3.361 s
成功构建页面的静态HTML — 6.906 s — 4006/4006 609.25页/秒
信息在26.047秒内完成建设

我目前正在评估使用Gatsby来加速旧的Heroku托管的Rails 3.x网站的速度，因为它像糖蜜一样慢。 它大约有100万页，因此增量构建是唯一的工作方式。 大多数页面不会改变，因此使其保持静态感觉就像是一次巨大的胜利，但是不断添加新页面，并对一些旧页面进行编辑。 用户期望在几秒钟内看到更改。 我的希望是向Rails应用程序添加足够的代码，使其成为JSON API服务器，并使用Gatsby生成一个新的前端，并在Netlify或S3等位置托管静态资产。

我当时以为我可以通过作业队列工作器来执行类似的Gatsby构建操作。 Rails API服务器知道页面何时更新，因此它将使用page_id（postgres DB中的键）创建“更新页面作业”，然后工作人员将使用带有PAGE_ID=1235 gatsby build的ENV var将其传递给Gatsby。

如果页面被删除，Rails API将创建一个作业，该作业要么直接从静态主机中删除资产，要么可能是Gatsby需要一些东西，所以我仍将使用另一个ENV变量来运行它。 （我想我至少需要页面的路径）。

我是否在误以为盖茨比与这种项目兼容？ 谢谢你的帮助。

我们有一个Alpha版本。 它不是增量构建，但至少是前进的道路。
您可以通过安装npm install --save gatsby@per-page-manifest来使用它

更多信息：
https://github.com/gatsbyjs/gatsby/pull/13004

目前，每个页面构建的@mpoisot尚无法正常工作。 我不确定您正在寻找这个项目的时间表。 如果查询较少，则即使没有增量构建，gatsby也可能适合您的站点。

cc @KyleAMathews @Moocar对此提供了更好的解释。

自上次更新以来已经过去了几个月，这似乎可以解决了。 我看到page-data.json的损坏已经存在，并且我一直在使用它。

是否有一组更具体的要求和任务来推动这一发展？ 我知道这是一个大问题，但是如果将其明显地分解为可以显示进步和吸引力的较小问题，它总是有帮助的。

@wardpeet @Moocar我不确定谁是对此进行ping操作的最合适的人员/列表，但是我认为你们都是这方面项目的最后一位活动人员。 关于此票证的主要目标是否有任何更新？

与@KyleAMathews达成良好https://twitter.com/dominicfallows/status/1169152367964643328?s=19

与@KyleAMathews达成良好https://twitter.com/dominicfallows/status/1169152367964643328?s=19

TLDR；

@KyleAMathews确认Gatsby正在使用Gastsby Cloud托管的增量构建功能。

具有增量构建的自托管/本地“ Gatsby Enterprise”版本是可能的，但是它们尚无法使用...。

Dominic Fallows-9月4日-与Gatsby OSS一样，我们选择的大多数供应商都提供自我管理/内部部署选项。 我们很乐意为这些费用付款，就像您为您提供的本地Gatsby Enterprise Cloud解决方案一样。

凯尔·马修斯（Kyle Mathews）-9月4日-是的-我们有一条非常清晰的路径来支持我们正在做的onprem版本-所有的都是Kubernetes，所以应该有可能-但当我们刚开始工作时onprem会增加很多开销运送有用的东西😅

Dominic Fallows-9月4日-现在真是个好消息！ 抱歉，如果我错过了其他地方讨论过的内容，但是对于企业和开发人员一样，onprem路线图将非常有用。

凯尔·马修斯（Kyle Mathews）-9月4日-现在距离我已经无法提供时间表了。 绝对不是今年，也不想明年承诺。 取决于我们可以多快地扩展收入和我们的工程团队

很可惜，因为它阻碍了使用盖茨比（Gatsby）作为发布商的工具，在发布商中，我们谈论了数以百万计的规范页面以及另一个相同或索引页面。

使用相同的概念/核心将“用例”作为单独的项目“弹出”是否有意义？

2020年决策的成败特征。 似乎是投资所有风投资金的好地方😀

Gatsby做了很多正确的事情，但是较长的构建时间使它在大型项目中绝对不可用：//因此，我们本周讨论了退出框架的原因。
请加快构建速度！

同意以上！ Gatsby要么陷入快速便捷的博客解决方案中，要么实施增量/更快的构建并准备好投入企业使用。

完全正确; 在大型项目中一再反驳。 如果没有增量构建，则不能选择盖茨比。

Gatsby Cloud上的增量构建解决了这些问题。 您可以在这里https://www.gatsbyjs.com/builds-beta/进行私人Beta版注册。

似乎没有任何迹象表明它支持增量构建-只是它具有“盖茨比站点的最快构建时间”。

我会担心这种隐含含义，即增量构建只能在托管的Gatsby服务上使用，而不能单独使用。

我明白了，您的意思是@dwightwatson ，网站上没有任何内容表示“递增”。 在Gatsby Days London，他们演示了构建，并且绝对是增量构建。 不确定如何完成，以及是否将它包含在Gatsby软件包中，或者是否只是它们提供的服务。

投资者必须以某种方式赚钱。 🙄

试图建立非常大的网站140k +页面

gatsby build有点好……但是部署起来很痛苦（zeit.co）

不确定如何在此添加标签，但我仍然将此作为问题。

@gomflo有什么方法可以建立您的网站？ 可能需要解决一些问题，以减少构建时间：)没有希望。

似乎没有任何迹象表明它支持增量构建-只是它具有“盖茨比站点的最快构建时间”。

我会担心这种隐含含义，即增量构建只能在托管的Gatsby服务上使用，而不能单独使用。

re this ^：如果我的gatsby存储库位于gitlab中而不是github中，我将能够使用gatsby cloud / build功能吗？

我之前可能已经提到过，但是关于原始问题/功能。 对于发布者而言，如果我们可以触发仅生成新页面并可能更新索引，那么盖茨比将变得有意义。 几乎没有任何发布者会关心更新旧的规范页面。

那么，我们将进行独立的部分更新还是没有机会？ 也许还有另一种方法可以只更新几页而不重建整个项目？

只是想更新一下，我的团队即将将PR发布到我们认为可以实现增量构建的Gatsby存储库中。 我们只是花一些时间来编写良好的PR并收紧代码，但完成后（在下一周左右），我将在此处进行更新。

只是想更新一下，我的团队即将将PR发布到我们认为可以实现增量构建的Gatsby存储库中。 我们只是花一些时间来编写良好的PR并收紧代码，但完成后（在下一周左右），我将在此处进行更新。

这是公关https://github.com/gatsbyjs/gatsby/pull/20785

对PR的进一步更新： https :

新的PR，着重于增量数据更改https://github.com/gatsbyjs/gatsby/pull/21523

通过合并＃21523和Gatsby Cloud中可用的增量构建，我相信此问题已解决。 它并不支持所有工作流程，但是我现在暂时关闭它，如果需要，将来最好再开一个新刊物以供将来使用。

它真的应该关闭吗？ 优化就是这样-一个优化。 这并不是真正的增量构建。 最重要的是，通过使用公共软件包无法获得通过Gatsby Cloud可用的任何内容。 对于该票证的特定意图，尚未解决任何问题。

它真的应该关闭吗？

基于https://github.com/gatsbyjs/gatsby/issues/5496#issuecomment -641005662，我认为此问题不应该解决，并且我不理解为什么删除了not stale标签。

这里有没有人尝试过或是否可能通过GatsbyJS webpack配置进行调整，以同时使用“ gatsby development”同时生成开发预览和生产构建版本？ （可能导致“增量构建”，而永久运行开发服务器的成本。）