Es ist nicht etwas, was Gatsby im Moment tut, aber es ist etwas, wonach die Leute gefragt haben. In Version 2 wurde daran gearbeitet , die Leistung auf größeren Websites zu verbessern, aber dafür gibt es noch kein Veröffentlichungsdatum.

@ m-allanson gibt es eine Diskussion / ein Problem, wie man damit umgeht? Ich habe es in dem von Ihnen aufgelisteten Link nicht gesehen. Ich bin gespannt auf Gespräche darüber, wie dies auf einem Host wie Netlify und mit einem CMS wie Wordpress / Drupal zu tun ist, für das derzeit viele HTTP-Anforderungen während des Builds erforderlich sind.

AFAIK Sie konnten keine inkrementellen Builds für netlify verwenden, da die Verzeichnisse .cache und public zwischen den Builds nicht beibehalten werden, sodass immer ein sauberer Build ausgeführt wird

Das ist gut zu wissen. Ich werfe eine Menge Ideen herum, die nicht gut durchdacht sind. Selbst wenn wir die Notwendigkeit von HTTP-Anforderungen eliminieren könnten, müssen wir dennoch sicherstellen, dass das Build-Tool auf die Verzeichnisse .cache und public verweisen kann, wodurch viele der Hosts eliminiert werden, die die Messlatte für den Eintrag senken.

Ein weiterer Anwendungsfall für das inkrementelle Erstellen ist, wenn Sie eine sehr große Site haben, die Sie in Teilen erstellen möchten. Beim gleichzeitigen Erstellen von ~ 5.000 Seiten wurde ein "Heap-out-of-Memory-Fehler" angezeigt.

Wir planen, dass unsere Website sehr groß wird, also testen wir Gatsby in größerem Maßstab. Wir haben versucht, so etwas wie path: './src/pages/${subPath}', wobei subPath process.argv[3] . Dies funktioniert gut, wenn wir Teile unserer Website mit gatsby develop hosten. Es umgeht auch die Probleme mit dem Speicherheap, wenn gatsby build für eine Site mit mehr als 5.000 Seiten verwendet wird. Damit es sich wirklich um eine Lösung handelt, hängt es wahrscheinlich von der Möglichkeit ab, ein Ausgabe-Unterverzeichnis im öffentlichen Ordner anzugeben: https://github.com/gatsbyjs/gatsby/pull/4756

Was ist, wenn ein anderer Ansatz verwendet wird, um dasselbe Ziel zu erreichen? Ich wollte eine Idee von euch machen und sehen, was die Leute denken. Nehmen wir also an, Sie haben eine 5k-Seiten-Website. Die ersten Seiten werden statisch generiert, aber jede Seite verfügt über eine Unterkomponente, die über den statischen Inhalt mit demselben Inhalt geladen wird, der aus statischen JSON-Dateien gelesen wird. Auf diese Weise kann ein Benutzer, der mitten am Tag eine Seite im CMS aktualisieren möchte, die Aktualisierung vornehmen, und nur diese statische JSON-Datei wird neu generiert und auf einem CDN bereitgestellt. Dann können Sie die gesamte Site einfach einmal am Tag als nächtlichen Prozess neu generieren. Der SEO-statische Inhalt ist tagsüber vielleicht nicht der aktuellste, aber ich sehe das nicht als große Sache an. Es wird nur während des nächtlichen Prozesses aktualisiert.

@robertschneiderman Wir sind auch auf das Speicherproblem --max_old_space_size .

Eine Sache, die mich an dieser Funktion beunruhigt, ist das Erstellen von Schemata. Wenn wir nicht jeden Beitrag zur Verfügung haben, aus dem Gatsby ein Schema erstellen kann, werden unsere Abfragen Fehler auslösen. Es wäre wirklich schön, wenn es eine Möglichkeit gäbe, Schemas an Gatsby zu übergeben oder zumindest Dummy-Entitäten während des Builds bereitzustellen, um die verschiedenen Formen zu demonstrieren, die sie annehmen könnten.

Ich denke darüber nach, Gatsby zu verwenden, um die Benutzeroberfläche für eine Inhaltswebsite mit über 5000 Elementen zu erstellen, von denen die meisten miteinander verbunden sind. Die Daten stammen von einem datenbankgesteuerten CMS.

Der Vorteil der Verwendung von Gatsby gegenüber einer Standard-API-gesteuerten React-Site besteht darin, dass ich einen Bruchteil der Zeit damit verbringen würde, die Daten-API und das Statusverwaltungssystem aufzubauen und zu warten, die die entfernten Daten laden und speichern. (Da ich vorhabe, diese Anwendung für mehrere Sites ähnlicher Größe bereitzustellen, scheint dies ein sehr wertvoller Vorteil zu sein.)

Der Nachteil bei der Verwendung von Gatsby in diesem Fall wäre die Tatsache, dass die gesamte Website selbst für die unbedeutendsten Inhaltsaktualisierungen neu erstellt werden müsste. Haben Sie vergessen, ein Komma hinzuzufügen? Erstellen Sie alle 5000 Seiten neu! Wer weiß überhaupt, wie lange das dauern würde? Dies ist ein noch größeres Problem, wenn man die Erfahrungen der CMS-Benutzer berücksichtigt. Sie sind es gewohnt, dass Änderungen unmittelbar nach dem Speichern auf der Website angezeigt werden. Bei Gatsby warten wir (zumindest) einige Minuten, bis die Änderung angezeigt wird.

Wenn es eine Möglichkeit gäbe, Builds für eine Teilmenge von Seiten auszulösen, wäre Gatsby die klare und endgültige Wahl. In diesem Moment ist es jedoch ein schwieriger Verkauf.

Übrigens habe ich viel daran gearbeitet, die Geschwindigkeit für größere Site-Builds für Version 2 zu verbessern. In der neuesten Beta-Version v2 können Sie möglicherweise 5000 Seiten in <1:30 erstellen. Es wird weitere Geschwindigkeitsverbesserungen geben.

Das ist unglaublich @KyleAMathews! Darauf freue ich mich auf jeden Fall! Lassen Sie mich wissen, wenn Sie gegen ein bildlastiges Blog testen möchten

@ KyleAMathews 5K ist schön, aber wir brauchen 1M 😉

Wenn wir Teile der Site separat kompilieren möchten, können wir beim Erstellen Flags setzen, damit gatsby-node nur die Teile der angegebenen Site generieren kann. Wir könnten dann die zuvor generierten statischen Dateien wieder hinzufügen. Dies funktioniert für uns, solange wir mit einem einfachen <a href> im Gegensatz zu einem <Link to > auf die zuvor generierten Dateien verlinken.

Ich frage mich, ob wir beim Verknüpfen mit zuvor generierten Dateien <Link to> zum Laufen bringen können, wenn wir zum Zeitpunkt der Erstellung einige der vorherigen data.json zusammenführen. Ich schaue mir das im Moment etwas genauer an.

Ich mache mir keine Sorgen um die Erstellungszeit, aber mehr mit dem Volumen der statischen Dateien, die ich für jedes Update hochladen muss. Wir haben mit Gatsby ein großes visuelles Portfolio gestartet und die hochzuladende statische Site ist über 150 MB groß
Meistens Bilder.
Dadurch ist die Site während eines Updates etwa 40 Minuten lang nicht verfügbar
Die Verfügbarkeit, einen Teil der Website neu zu erstellen, ist definitiv eine Funktion, die Gatsby stärken würde.
Ich plane, Gatsby für eine neue Site zu verwenden, aber ich werde die Site in einen statischen und dynamischen Teil unter Verwendung eines traditionellen PHP-CMS für den News-Teil unterteilen.

@rbmedia Möglicherweise möchten Sie einen Host in Betracht ziehen, der eine Bereitstellungsumschaltung wie Netlify durchführt, damit Ihre aktuelle Site so lange ausgeführt wird, bis Ihre neue Version fertig ist.

Danke Matt, ich werde es in Betracht ziehen!
Ich habe in der Vergangenheit einige News-Websites mit Drupal erstellt. Jedes Update musste innerhalb kurzer Zeit (weniger als 2 Minuten) online sein. Ich würde Gatsby in Zukunft gerne für diese Art von Websites verwenden.

Gibt es Neuigkeiten zu diesem Thema? Wir planen eine Site mit rund 100.000 Seiten und inkrementelle Builds wären fantastisch.

Erstellen Sie einen anderen Pfad als statischen Standard-Seitenordner, nicht '/ public'.
Kopieren Sie nach dem Ausführen von gatsby build die Datei ../public/* in den Standardpfad.

Hiya!

Dieses Problem ist behoben. Gruselig leise. 👻

Wir haben viele Probleme, daher schließen wir Probleme derzeit nach 30 Tagen Inaktivität. Seit dem letzten Update hier sind mindestens 20 Tage vergangen.

Wenn wir dieses Problem verpasst haben oder wenn Sie es offen halten möchten, antworten Sie bitte hier. Sie können auch das Label "not stale" hinzufügen, um dieses Problem offen zu halten!

Vielen Dank, dass Sie Teil der Gatsby-Community sind! 💪💜

Ich denke immer noch nicht, dass dies in Gatsby behoben ist. Irgendwelche Neuigkeiten bei TeamGatsby?

Es ist ein langjähriges Problem, weil es wirklich schwer zu beheben ist, ohne viel darüber nachzudenken. @ Moocar hat ein offenes Problem, um uns zumindest einen Schritt in die richtige Richtung zu bringen.

Verfolgt Gatsby derzeit, welche GraphQL-Knoten auf einer bestimmten Seite abgerufen werden? In diesem Fall erscheint es sinnvoll, inkrementelle Neuerstellungen basierend auf Änderungen an den Daten hinzuzufügen. Das ist die halbe Arbeit, nein?

Der andere Teil der Arbeit besteht darin, Quell-Plugins mit einem Cache zu versehen und Plugin-Entwickler zu ermutigen, nur geänderte Daten abzurufen, wo dies möglich ist. In vielen Fällen ist dies trivial.

@coreyward Ja, Gatsby verfolgt jeden Knoten, der für eine Abfrage zurückgegeben wird (über page-dependency-resolver.js ). Dies ermöglicht es gatsby develop , Abfragen nur für geänderte Daten erneut auszuführen. Wir speichern diese Informationen derzeit nicht auf der Festplatte, daher wird sie noch nicht für gatsby build aber das ist definitiv der Plan.

Ich weiß, dass dies für unser Team die Entscheidung sein wird, Gatsby nicht für den Wiederaufbau unserer Flaggschiff-Website im Jahr 2019 einzusetzen. Ich hoffe wirklich, dass es veröffentlicht werden kann oder zumindest am Horizont steht, wenn wir mit dem Bau beginnen. Wir unterstützen Hunderte von Webautoren, die im Laufe des Arbeitstages verschiedene Teile der Website bearbeiten. Wenn sie auf Speichern klicken, erwarten sie ziemlich genau, dass der Inhalt aktualisiert wird. Es ist nicht ungewöhnlich, dass sie zurückgehen, nur um ein Komma zu korrigieren oder das Datum auf dem Beitrag zu ändern.

@mattbloomfield Wir haben mehr Kunden, die daran interessiert sind, also haben wir dies ganz oben auf der Prioritätenliste.

Wir implementieren Gatsby mit einem Drupal 8-Backend unter Verwendung des Gatsby-Source-Graphql-Plugins, und die Leistung ist bisher kein Problem, da ~ 4000 Seiten in <30 Sekunden erstellt wurden. Wir ziehen alle Daten in gatsby-node ab, anstatt Tausende von StaticQuerys auszuführen und die Bildverarbeitung vorerst zu umgehen.

`` `
Erfolgreiche Ausführung von Graphql-Abfragen - 3.088 s - 4008/4008 1311.56 Abfragen / Sekunde
Erfolg Ausschreiben von Seitendaten - 0,070 s
Erfolg Schreibumleitungsdaten - 0,001 s
Erfolg Erstellen Sie Manifest und verwandte Symbole - 0,117 s
Erfolg auf PostBootstrap - 0,127 s

Info Bootstrap fertig - 15.751 s

Erfolg Erstellen von Produktions-JavaScript- und CSS-Bundles - 3.361 s
Erfolg Erstellen von statischem HTML für Seiten - 6.906 s - 4006/4006 609.25 Seiten / Sekunde
info Fertig Gebäude in 26.047 Sek

Ich evaluiere derzeit die Verwendung von Gatsby, um eine alte, von Heroku gehostete Rails 3.x-Site zu beschleunigen, die so langsam wie Melasse ist. Es hat ungefähr 1 Million Seiten, so dass inkrementelle Builds die einzige Möglichkeit sind, wie es funktionieren würde. Die meisten Seiten ändern sich nicht, so dass es sich wie ein großer Gewinn anfühlt, sie statisch zu machen. Es werden jedoch ständig neue Seiten hinzugefügt und einige alte Seiten bearbeitet. Benutzer erwarten, dass die Änderungen innerhalb von Sekunden angezeigt werden. Meine Hoffnung war es, der Rails-App gerade genug Code hinzuzufügen, um sie zu einem JSON-API-Server zu machen, und mit Gatsby ein neues Frontend mit statischen Assets zu generieren, die irgendwo wie Netlify oder S3 gehostet werden.

Ich dachte, ich könnte so etwas wie einen inkrementellen Gatsby-Build über einen Job Queue Worker ausführen. Der Rails-API-Server weiß, wann eine Seite aktualisiert wird, und erstellt daher mithilfe der page_id (einem Schlüssel in der Postgres-Datenbank) einen 'Seitenjob aktualisieren'. Der Worker übergibt diesen mit einer ENV-Variable mit etwa PAGE_ID=1235 gatsby build an Gatsby

Wenn eine Seite gelöscht wird, erstellt die Rails-API einen Job, der entweder die Assets direkt vom statischen Host löscht, oder es wird möglicherweise etwas von Gatsby benötigt, sodass ich dies immer noch mit einer anderen ENV-Variablen ausführen würde. (Ich denke, ich brauche mindestens den Pfad der Seite).

Belle ich den falschen Baum an und denke, dass Gatsby mit dieser Art von Projekt kompatibel ist? Vielen Dank für jede Hilfe.

Wir haben eine Alpha-Version. Es sind noch keine inkrementellen Builds, aber zumindest der Weg nach vorne.
Sie können es verwenden, indem Sie npm install --save gatsby@per-page-manifest installieren

Mehr Info:
https://github.com/gatsbyjs/gatsby/pull/13004

@mpoisot pro Seite pro Seite

cc @KyleAMathews @Moocar , um dies besser zu erklären.

Pingen Sie dies an, da es einige Monate seit dem letzten Update vergangen ist und es der Ort der Aktion zu sein scheint. Ich sehe, dass die Seite-data.json zusammengebrochen ist und ich sie benutzt habe.

Gibt es konkretere Anforderungen und Aufgaben, die dies vorantreiben? Ich verstehe, dass es ein großes Problem ist, aber es hilft immer, wenn es sichtbar in kleinere Probleme zerlegt wird, die Fortschritt und Traktion zeigen können.

@wardpeet @Moocar Ich bin mir nicht sicher, wer die am besten geeignete Person / Liste ist, um darauf zu pingen , aber ich sehe Sie beide als die letzten Aktivisten aus dem Projekt hier. Gibt es Aktualisierungen zum Hauptziel dieses Tickets?

Eine gute Convo mit @KyleAMathews über inkrementelle Builds und wie sie geliefert werden könnten https://twitter.com/dominicfallows/status/1169152367964643328?s=19

Eine gute Convo mit @KyleAMathews über inkrementelle Builds und wie sie geliefert werden könnten https://twitter.com/dominicfallows/status/1169152367964643328?s=19

TLDR;

@KyleAMathews bestätigte, dass Gatsby an den in der Gastsby Cloud gehosteten inkrementellen Build-Funktionen arbeitet.

Selbst gehostete / lokale "Gatsby Enterprise" -Version mit inkrementellen Builds ist möglich, aber sie arbeiten noch nicht daran ....

Dominic Fallows - 4. September - Die meisten von uns ausgewählten Anbieter bieten eine selbstverwaltete / lokale Option an, wie dies bei Gatsby OSS der Fall ist. Wir bezahlen diese gerne, wie wir es bei einer lokalen Gatsby Enterprise Cloud-Lösung von Ihnen tun würden.

Kyle Mathews - 4. September - ja sicher - wir haben einen ziemlich klaren Weg für die Unterstützung von Onprem-Versionen von dem, was wir tun - es sind alles Kubernetes, also sollte es möglich sein - aber Onprem fügt viel Overhead hinzu, wenn wir anfänglich nur arbeiten beim Versand etwas, das funktioniert 😅

Dominic Fallows - 4. September - Das sind großartige Neuigkeiten! Es tut mir leid, wenn ich das an anderer Stelle besprochene verpasst habe, aber diese vorläufige Roadmap wäre für Unternehmen und Entwickler gleichermaßen nützlich, um sie zu sehen.

Kyle Mathews - 4. September - Im Moment ist es weit genug weg, dass ich keinen Zeitplan angeben konnte. Auf keinen Fall dieses Jahr und würde es auch nächstes Jahr nicht versprechen wollen. Kommt darauf an, wie schnell wir den Umsatz skalieren können und unser Engineering-Team

Es ist schade, dass es die Verwendung von Gatsby als Tool für Verlage blockiert, bei denen wir über Millionen kanonischer Seiten und andere gleiche oder indexierte Seiten sprechen.

Wäre es nicht sinnvoll, einen solchen Anwendungsfall als separates Projekt mit denselben Konzepten / Kern "auszuwerfen"?

Funktion für 2020-Entscheidungen treffen oder unterbrechen. Scheint ein guter Ort zu sein, um all das VC-Geld zu investieren 😀

Gatsby macht viele Dinge richtig, aber lange Bauzeiten machen es in größeren Projekten absolut unbrauchbar: / Wir haben diese Woche darüber gesprochen, uns aus diesem Grund vom Framework zu entfernen.
Bitte machen Sie einen schnelleren Build möglich!

Stimme oben zu! Gatsby wird entweder zu einer schnellen und einfachen Blogging-Lösung oder implementiert inkrementelle / schnellere Builds und wird unternehmensbereit.

Absolut korrekt; bei größeren Projekten immer wieder dagegen stoßen. Ohne inkrementelle Builds ist Gatsby keine Option.

Inkrementelle Builds auf Gatsby Cloud beheben diese Probleme. Sie können sich hier für die private Beta anmelden: https://www.gatsbyjs.com/builds-beta/

Nichts davon scheint darauf hinzudeuten, dass es inkrementelle Builds unterstützt - nur, dass es die "schnellsten Build-Zeiten für Gatsby-Sites" hat.

Ich wäre besorgt über die Implikation, dass inkrementelle Builds nur für einen gehosteten Gatsby-Dienst verfügbar sind und nicht als eigenständige Verwendung verfügbar sind.

Ich verstehe, was du meinst @dwightwatson Auf der Website gibt es nichts, was besagt, dass es "inkrementell" ist. Bei den Gatsby Days London haben sie Builds vorgeführt und es waren definitiv inkrementelle Builds. Ich bin mir nicht sicher, wie es gemacht wird und ob es Teil des Gatsby-Pakets sein wird oder ob es nur ein Service sein wird, den sie anbieten.

Investoren müssen irgendwie ihr Geld zurückverdienen. 🙄

versuchen, sehr große Website 140k + Seiten zu erstellen

gatsby build ist etwas gut ... aber die Bereitstellung ist schmerzhaft (zeit.co)

Wir sind uns nicht sicher, wie wir dem ein Etikett hinzufügen sollen, aber ich schreibe dies immer noch als Problem auf.

@gomflo gibt es eine Möglichkeit, wie ich Ihre Website erstellen kann? Möglicherweise müssen einige niedrig hängende Früchte gelöst werden, um die Bauzeiten zu verbessern :) Keine Versprechungen.

Nichts davon scheint darauf hinzudeuten, dass es inkrementelle Builds unterstützt - nur, dass es die "schnellsten Build-Zeiten für Gatsby-Sites" hat.

Ich wäre besorgt über die Implikation, dass inkrementelle Builds nur für einen gehosteten Gatsby-Dienst verfügbar sind und nicht als eigenständige Verwendung verfügbar sind.

Zu diesem Thema: Wenn mein Gatsby-Repo in Gitlab und nicht in Github ist, kann ich dann Gatsby Cloud / Build-Funktionen verwenden?

Ich hätte das vielleicht schon einmal erwähnt, beziehe mich aber auf das ursprüngliche Problem / Feature. Für Verlage ist Gatsby sinnvoll, wenn wir die einzige Generation neuer Seiten auslösen und möglicherweise auf Indizes aktualisieren können. Kaum ein Verlag würde sich darum kümmern, alte kanonische Seiten zu aktualisieren.

Haben wir also ein eigenständiges Teil-Update oder keine Chancen? Vielleicht gibt es eine andere Möglichkeit, nur ein paar Seiten zu aktualisieren und nicht das gesamte Projekt neu zu erstellen?

Ich wollte nur aktualisieren, dass mein Team kurz davor steht, eine PR im Gatsby-Repo zu veröffentlichen, die unserer Meinung nach inkrementelle Builds ermöglicht. Wir nehmen uns nur etwas Zeit, um eine gute PR zu schreiben und den Code zu straffen, aber ich werde hier aktualisieren, wenn wir fertig sind (in der nächsten Woche oder so).

Ich wollte nur aktualisieren, dass mein Team kurz davor steht, eine PR im Gatsby-Repo zu veröffentlichen, die unserer Meinung nach inkrementelle Builds ermöglicht. Wir nehmen uns nur etwas Zeit, um eine gute PR zu schreiben und den Code zu straffen, aber ich werde hier aktualisieren, wenn wir fertig sind (in der nächsten Woche oder so).

Hier ist die PR https://github.com/gatsbyjs/gatsby/pull/20785

Weitere Aktualisierung der PR: https://github.com/gatsbyjs/gatsby/pull/20785#issuecomment -579355927

Neue PR mit Schwerpunkt auf inkrementellen Datenänderungen https://github.com/gatsbyjs/gatsby/pull/21523

Ich glaube, dass dieses Problem behoben ist, da # 21523 in Gatsby Cloud zusammengeführt und inkrementelle Builds verfügbar sind. Es werden nicht alle Workflows unterstützt, aber ich werde dies vorerst schließen, und es ist möglicherweise besser, in Zukunft eine neue Ausgabe für zukünftige Bemühungen zu öffnen, falls dies erforderlich sein sollte.

Sollte es wirklich geschlossen sein? Die Optimierung war genau das - eine Optimierung. Es waren keine wirklich inkrementellen Builds. Darüber hinaus ist alles, was über Gatsby Cloud verfügbar ist, nicht über das öffentliche Paket verfügbar. Für die spezifische Absicht dieses Tickets wurde nichts gelöst.

Sollte es wirklich geschlossen sein?

Basierend auf https://github.com/gatsbyjs/gatsby/issues/5496#issuecomment -641005662 denke ich nicht, dass dieses Problem geschlossen bleiben sollte, und ich verstehe nicht, warum das Label not stale entfernt wurde .

Hat hier jemand versucht oder weiß, ob es möglich ist, die GatsbyJS-Webpack-Konfiguration zu optimieren, um gleichzeitig die Entwicklungsvorschau und die Produktions-Build-Version mit "gatsby Develop" zu erstellen? (Möglicherweise resultierende "inkrementelle Builds" mit Kosten für den ewigen Betrieb des Entwicklungsservers.)