ギャツビーが今していることではありませんが、人々が求めていることです。 バージョン2では、大規模なサイトでのパフォーマンスを改善するための

@ m-allansonこれを処理する方法についての議論/問題はありますか？ あなたがリストしたリンクにそれが表示されませんでした。 Netlifyのようなホストでこれを処理する方法と、現在ビルド中に多くのHTTPリクエストを必要とするWordpress / DrupalのようなCMSを使用する方法についての会話を聞きたいです。

.cache publicディレクトリと

それは知っておくと良いことです。 私はよく考えられていないたくさんのアイデアを投げかけています。 したがって、HTTPリクエストの必要性を排除できたとしても、ビルドツールで.cacheディレクトリとパブリックディレクトリを参照できるようにする必要があります。これにより、エントリの基準を下げるホストの多くが排除されます。

インクリメンタルビルドのもう1つのユースケースは、パーツでビルドする非常に大規模なサイトがある場合です。 一度に最大5,000ページをビルドすると、「メモリ不足エラー」が発生していました。

私たちはサイトを非常に大きくすることを計画しているので、ギャツビーをより大規模にテストしています。 subPathがprocess.argv[3]ある、このpath: './src/pages/${subPath}',ようなことを試みました。 これは、サイトの一部をgatsby developホストする場合にうまく機能します。 また、 gatsby buildページ以上のサイトでhttps ：

同じ目標を達成するために別のアプローチが使用された場合はどうなりますか。 私はあなたたちによってアイデアを実行し、人々がどう思うかを見たかったのです。 それで、あなたが5kページのウェブサイトを持っているとしましょう。 最初のページは静的に生成されますが、各ページには、静的jsonファイルから読み取られるのと同じコンテンツを持つ静的コンテンツの上に読み込まれるサブコンポーネントがあります。 このようにして、ユーザーが1日の途中でCMSの1つのページを更新したい場合、更新を行うことができ、その静的jsonファイルだけが再生成されてCDNにデプロイされます。 次に、サイト全体を1日1回、夜間のプロセスとして再生成できます。 seoの静的コンテンツは、日中は最新ではないかもしれませんが、それは大したことではないと思います。 毎晩のプロセス中に更新されます。

@robertschneidermanメモリの問題にも--max_old_space_sizeフラグを介して。

この機能について私が心配していることの1つは、スキーマの構築です。 gatsbyがスキーマを構築するために利用できるすべての投稿がない場合、クエリはエラーをスローします。 スキーマをgatsbyに渡す方法があるか、少なくともビルド中にダミーエンティティを提供して、さまざまな形状を示す方法があれば、本当に便利です。

Gatsbyを使用して、5000を超えるアイテムを含むコンテンツサイトのUIを構築することを検討しています。そのほとんどは、相互に関連しています。 データはデータベース駆動型CMSから取得されます。

標準のAPI駆動型ReactサイトよりもGatsbyを使用する利点は、リモートデータをロードして保存するデータAPIと状態管理システムの構築と保守にほんのわずかな時間を費やすことができることです。 （このアプリケーションを同じサイズの複数のサイトに展開することを計画しているので、これは非常に価値のある利点のようです。）

この場合にGatsbyを使用することの欠点は、最も重要でないコンテンツの更新でさえ、サイト全体を再構築する必要があるという事実です。 カンマを追加するのを忘れましたか？ 5000ページすべてを再構築してください！ それがどれくらいかかるか誰が知っていますか？ これは、CMSユーザーのエクスペリエンスを考慮すると、さらに問題になります。CMSユーザーは、保存した直後にサイトに変更が表示されるのを確認することに慣れています。 Gatsbyでは、変更が表示されるまで（少なくとも）数分待つことを検討しています。

ページのサブセットのビルドをトリガーする方法があれば、Gatsbyは明確で決定的な選択になります。 しかし、現時点では、それは難しい販売です。

ところで、私はv2の大規模なサイトビルドの速度を改善するために多くの作業を行ってきました。 最新のv2ベータ版では、1：30未満で5000ページを作成できる可能性があります。 今後さらに速度が向上します。

それは素晴らしい@KyleAMathewsです！ 絶対に楽しみです！ 画像の多いブログに対してテストしたい場合はお知らせください

@KyleAMathews 5Kは素晴らしいですが、1Mが必要です😉

サイトの一部を個別にコンパイルする場合は、ビルド時にフラグを設定して、gatsby-nodeが指定されたサイトの一部のみを生成することを認識できるようにすることができます。 次に、以前に生成された静的ファイルを追加し直すことができます。 限り、私たちのためにこの作品は、私たちがして、以前に生成されたファイルへのリンクとしての基本的な<a href>とは対照的に、 <Link to > 。

ビルド時に以前のdata.json一部をマージした場合、以前に生成されたファイルにリンクするときに<Link to>機能させることができるかどうか疑問に思っています。 現時点では、もう少し詳しく調べます。

ビルド時間については心配していませんが、更新のためにアップロードする必要のある静的ファイルの量については、Gatsbyで大規模なビジュアルポートフォリオを立ち上げました。アップロードする静的サイトは150MBを超えています。
主に画像。
これにより、更新中は約40分でサイトが利用できなくなります
サイトの一部を再構築できることは、間違いなくギャツビーを後押しする機能です。
新しいサイトにGatsbyを使用する予定ですが、ニュース部分に従来のphp CMSを使用して、サイトを静的部分と動的部分に分割します。

@rbmediaは、Netlifyのようなデプロイメントの切り替えを行うホストを検討して、新しいバージョンの準備ができるまで現在のサイトが実行され続けるようにすることをお勧めします。

ありがとうマット、私はそれを検討します！
私は過去にDrupalを使用していくつかのニュースWebサイトを構築しましたが、更新は短時間（2分未満）でオンラインにする必要がありました。 将来的にはこの種のサイトにギャツビーを使いたいです。

この問題に関するニュースはありますか？ 私たちは約10万ページのサイトを計画しており、インクリメンタルビルドは素晴らしいでしょう。

'/ public'ではなく、デフォルトの静的ページフォルダとして別のパスを作成します。
gatsby buildを実行した後、.. / public / *をデフォルトのパスにコピーします。

ひや！

この問題は静かになりました。 不気味な静か。 👻

多くの問題が発生しているため、現在、30日間使用されなかった後に問題をクローズしています。 ここでの最後の更新から少なくとも20日が経過しています。

この問題を見逃した場合、または開いたままにしておきたい場合は、ここに返信してください。 この問題を開いたままにするために、「古くない」というラベルを追加することもできます。

Gatsbyコミュニティに参加していただきありがとうございます。 💪💜

私はまだこれがギャツビーで修正/サポートされているとは思いません。 TeamGatsbyのニュースはありますか？

それについて深く考えずに修正するのは本当に難しいので、それは長年の問題です。 @Moocarには、少なくとも正しい方向への一歩を踏み出すための未解決の問題があります。

Gatsbyは現在、特定のページで取得されたGraphQLノードを追跡していますか？ もしそうなら、データへの変更に基づいて増分再構築を追加することは実行可能であるように思われます。 それは仕事の半分ですよね？

もう1つの作業は、ソースプラグインにキャッシュを提供し、プラグイン開発者が可能な場合は変更されたデータのみをフェッチするように促すことです。 多くの場合、これは些細なことです。

@coreywardはい、Gatsbyはクエリに対して返されるすべてのノードを追跡します（ page-dependency-resolver.jsを介して）。 これが、変更されたデータに対してのみクエリを再実行するgatsby developの機能を強化するものです。 現在、その情報をディスクに保存していないため、まだgatsby buildは使用されていませんが、それは間違いなく計画です。

私たちのチームにとって、これは2019年の旗艦サイトの再構築にギャツビーを使用することに反対する決定になることを私は知っています。 ビルドを開始するときに、リリースされるか、少なくとも地平線上にあることを本当に望んでいます。 私たちは、営業日を通してサイトのさまざまな部分を編集する何百人ものWeb作成者をサポートしています。 保存を押すと、コンテンツが更新されることをほぼ期待しています。 カンマを修正したり、投稿の日付を変更したりするためだけに戻ってくることも珍しくありません。

@mattbloomfieldこれに関心のある顧客が増えているため、優先順位リストの上位にあります。

gatsby-source-graphqlプラグインを使用してdrupal8バックエンドでgatsbyを実装していますが、パフォーマンスは今のところ問題ではなく、30秒未満で最大4000ページがビルドされます。 何千ものStaticQueryを実行するのではなく、gatsby-node内のすべてのデータをプルし、今のところ画像処理をバイパスしています。

`` `
成功実行graphqlクエリ— 3.088秒— 4008 / 40081311.56クエリ/秒
ページデータの書き込みに成功—0.070秒
リダイレクトデータの書き込みに成功—0.001秒
成功マニフェストと関連アイコンの作成—0.117秒
PostBootstrapでの成功—0.127秒

情報ブートストラップが終了しました-15.751秒

成功本番JavaScriptおよびCSSバンドルの構築—3.361秒
成功ページの静的HTMLの構築— 6.906秒— 4006 / 4006609.25ページ/秒
info26.047秒で構築が完了しました

私は現在、Gatsbyを使用して、糖蜜のように遅い、Herokuがホストする古いRails3.xサイトを高速化することを評価しています。 約100万ページあるため、インクリメンタルビルドが唯一の方法です。 ほとんどのページは変更されないため、静的にすることは大きな勝利のように感じますが、新しいページが絶えず追加され、一部の古いページが編集されます。 ユーザーは、数秒以内に変更が表示されることを期待しています。 RailsアプリにJSONAPIサーバーにするのに十分なコードを追加し、NetlifyやS3などの場所でホストされている静的アセットを使用してGatsbyで新しいフロントエンドを生成することを望んでいました。

ジョブキューワーカーを介してインクリメンタルGatsbyビルドを実行するようなことができると思っていました。 Rails APIサーバーはページがいつ更新されるかを知っているため、page_id（postgres DBのキー）を使用して「ページ更新ジョブ」を作成し、ワーカーはそれをPAGE_ID=1235 gatsby buildようなENV変数でGatsbyに渡します。

ページが削除された場合、Rails APIは、静的ホストからアセットを直接削除するジョブを作成するか、Gatsbyから何かが必要なため、別のENV変数を使用して実行します。 （少なくともページのパスが必要だと思います）。

ギャツビーはこの種のプロジェクトと互換性があると思って、間違った木を吠えていますか？ 助けてくれてありがとう。

アルファ版がアップしています。 まだインクリメンタルビルドではありませんが、少なくとも今後の道のりです。
npm install --save gatsby@per-page-manifestインストールして使用できます

より詳しい情報：
https://github.com/gatsbyjs/gatsby/pull/13004

@mpoisotは今のところ、ページごとの構築はまだ機能していません。 このプロジェクトでどのような時間枠を見ているのかわかりません。 クエリが少ない場合は、増分ビルドがなくてもgatsbyがサイトに適している可能性があります。

cc @KyleAMathews @Moocarは、これをよりよく説明します。

前回の更新から数か月が経過しており、アクションの場所のようであるため、これにpingを送信します。 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が

インクリメンタルビルドを備えたセルフホスト/オンプレミスの「GatsbyEnterprise」バージョンは可能ですが、まだ機能していません。

Dominic Fallows- 9月4日-私たちが選択するほとんどのベンダーは、Gatsby OSSと同様に、自己管理/オンプレミスのオプションを提供しています。 オンプレミスのGatsbyEnterprise Cloudソリューションと同様に、喜んで支払います。

Kyle Mathews- 9月4日-確かに—私たちが行っていることのonpremバージョンをサポートするためのかなり明確なパスがあります—それはすべてKubernetesなので、可能であるはずです—しかし、onpremは、最初に作業しているときに多くのオーバーヘッドを追加しますうまくいくものを出荷することについて😅

Dominic Fallows- 9月4日-これは素晴らしいニュースです。 他の場所で説明されていることを見逃してしまった場合は申し訳ありませんが、そのオンプレムロードマップは企業と開発者の両方にとって非常に役立ちます。

カイル・マシューズ-9月4日-タイムラインを与えることができなかったので、今は十分に遠いです。 今年は絶対にありませんし、来年も約束したくありません。 収益をどれだけ迅速に拡大できるか、およびエンジニアリングチームによって異なります

何百万もの正規のページと別の同じページまたはインデックス付きのページについて話す出版社向けのツールとしてGatsbyを使用することをブロックしているので、残念です。

同じ概念/コアを使用する別個のプロジェクトとして、そのようなユースケースを「排除」することは意味がありませんか？

2020年の決定のための機能を作成または中断します。 ベンチャーキャピタルのお金をすべて投資するのに良い場所のようです😀

Gatsbyは多くのことを正しく行いますが、ビルド時間が長いため、大規模なプロジェクトではまったく使用できません：/今週は、そのためにフレームワークからの移行について説明しました。
より高速なビルドを実現してください！

上記に同意します！ Gatsbyは、すばやく簡単なブログソリューションに移行するか、インクリメンタル/高速ビルドを実装してエンタープライズ対応になります。

絶対に正しい。 大規模なプロジェクトでは、これに何度もぶつかります。 インクリメンタルビルドがない場合、ギャツビーはオプションではありません。

Gatsby Cloudのインクリメンタルビルドは、これらの問題を修正します。 こちらからプライベートベータにサインアップできますhttps://www.gatsbyjs.com/builds-beta/

ただし、インクリメンタルビルドをサポートしていることを示唆するものは何もないようです。「Gatsbyサイトのビルド時間が最も速い」というだけです。

インクリメンタルビルドは、スタンドアロンで使用するのではなく、ホストされているGatsbyサービスでのみ使用できるという意味が気になります。

@dwightwatsonの意味が

投資家はどうにかしてお金を取り戻さなければなりません。 🙄

非常に大きなウェブサイト14万ページ以上を構築しようとしています

gatsby buildはやや良いです…しかし、展開を行うのは苦痛です（zeit.co）

これにラベルを追加する方法がわからないが、私はこれをまだ問題として置いている。

@gomflo私があなたのサイトを構築する方法はありますか？ ビルド時間を改善するために解決すべきいくつかの低い成果があるかもしれません:)約束はありません。

ただし、インクリメンタルビルドをサポートしていることを示唆するものは何もないようです。「Gatsbyサイトのビルド時間が最も速い」というだけです。

インクリメンタルビルドは、スタンドアロンで使用するのではなく、ホストされているGatsbyサービスでのみ使用できるという意味が気になります。

re this ^：私のgatsbyリポジトリがgithubではなくgitlabにある場合、gatsbyクラウド/ビルド機能を使用できますか？

前にも言ったかもしれませんが、元の問題/機能についてです。 出版社にとって、ギャツビーは、新しいページの唯一の生成をトリガーし、インデックスを更新することができれば意味があります。 古い正規ページの更新を気にする出版社はほとんどありません。

では、スタンドアロンの部分的な更新があるのでしょうか、それともチャンスがないのでしょうか。 たぶん、数ページだけを更新し、プロジェクト全体を再構築しない別の方法がありますか？

私のチームが、インクリメンタルビルドを可能にすると思われるPRをGatsbyリポジトリに公開しようとしていることを更新したかっただけです。 良いPRを書いてコードを強化するのに少し時間がかかっていますが、完了したら（来週かそこらで）ここで更新します。

私のチームが、インクリメンタルビルドを可能にすると思われるPRをGatsbyリポジトリに公開しようとしていることを更新したかっただけです。 良いPRを書いてコードを強化するのに少し時間がかかっていますが、完了したら（来週かそこらで）ここで更新します。

これがPRですhttps://github.com/gatsbyjs/gatsby/pull/20785

PRのさらなる更新： https ：

増分データ変更に焦点を当てた新しいPRhttps ：//github.com/gatsbyjs/gatsby/pull/21523

＃21523が統合され、Gatsby Cloudでインクリメンタルビルドが利用可能になったため、この問題は解決されたと思います。 すべてのワークフローをサポートしているわけではありませんが、今はこれを閉じます。必要に応じて、将来の取り組みのために新しい問題を開く方がよい場合があります。

本当に閉鎖すべきですか？ 最適化はまさにそれでした-最適化。 それは本当にインクリメンタルビルドではありませんでした。 その上、Gatsby Cloudで利用できるものはすべて、パブリックパッケージの使用では利用できません。 このチケットの特定の目的については、何も解決されていません。

本当に閉鎖すべきですか？

https://github.com/gatsbyjs/gatsby/issues/5496#issuecomment -641005662に基づくと、この問題を解決したままにしておくべきではないと思います。また、 not staleラベルが削除された理由がわかりません。 。

ここで誰かがGatsbyJSwebpack構成を微調整して、「gatsbydevelop」で開発プレビューと本番ビルドバージョンの両方を同時に作成しようとしたか、それが可能かどうかを知っていますか？ （おそらく、開発サーバーを永久に実行するコストを伴う「インクリメンタルビルド」が発生します。）