Ce n'est pas quelque chose que Gatsby fait pour le moment, mais c'est quelque chose que les gens ont demandé. Il y a eu des travaux dans la version 2 pour améliorer les performances sur les plus grands sites, mais il n'y a pas encore de date de sortie pour cela.

@ m-allanson y a-t-il une discussion / un problème sur la façon de gérer cela? Je ne l'ai pas vu dans le lien que vous avez répertorié. Je suis curieux d'entendre des conversations sur la façon de gérer cela sur un hôte comme Netlify et en utilisant un CMS comme Wordpress / Drupal qui nécessite actuellement beaucoup de requêtes HTTP lors de la construction.

AFAIK vous ne pourriez pas utiliser de builds incrémentiels sur netlify car les répertoires .cache et public ne sont pas conservés entre les builds, donc il fera toujours des builds propres

C'est bon à savoir. Je lance une tonne d'idées qui ne sont pas bien pensées. Ainsi, même si nous pouvions éliminer le besoin de requêtes HTTP, nous devons tout de même nous assurer que les répertoires .cache et publics peuvent être référencés par l'outil de construction qui élimine de nombreux hôtes qui abaissent la barre d'entrée.

Un autre cas d'utilisation de la construction incrémentielle est lorsque vous avez un très grand site que vous souhaitez créer en plusieurs parties. J'obtenais une "erreur de tas de mémoire" lors de la création d'environ 5 000 pages à la fois.

Nous prévoyons que notre site devienne très grand, nous testons donc Gatsby à plus grande échelle. Nous avons essayé de faire quelque chose comme ceci path: './src/pages/${subPath}', où subPath est process.argv[3] . Cela fonctionne bien lorsque nous hébergeons des parties de notre site avec gatsby develop . Cela évite également les problèmes avec le tas de mémoire lors de l'utilisation de gatsby build pour un site de plus de 5 000 pages. Pour que ce soit vraiment une solution, cela dépendrait probablement de la possibilité de spécifier un sous-répertoire de sortie dans le dossier public: https://github.com/gatsbyjs/gatsby/pull/4756

et si une autre approche était utilisée pour atteindre le même objectif. Je voulais vous proposer une idée et voir ce que les gens pensent. Disons donc que vous avez un site Web de 5 000 pages. Les pages initiales seraient générées statiquement, mais chaque page aura un sous-composant qui se chargera au-dessus du contenu statique avec le même contenu que celui lu à partir de fichiers json statiques. De cette façon, si un utilisateur souhaitait mettre à jour une page dans le CMS en milieu de journée, il peut effectuer la mise à jour et seul ce fichier json statique serait régénéré et déployé sur un CDN. Ensuite, vous pouvez simplement régénérer l'ensemble du site peut-être une fois par jour comme un processus nocturne. Le contenu statique de référencement n'est peut-être pas le plus à jour de la journée, mais je ne vois pas cela comme un gros problème. Il sera simplement mis à jour pendant le processus nocturne.

@robertschneiderman, nous avons également abordé le problème de la mémoire. Nous sommes plus près de 1500 pages, mais une quantité folle d'images (blog design). Nous avons désactivé les mappages sources et arrêté la compilation de télécharger les fichiers image, mais avons finalement dû modifier la commande de construction pour augmenter la mémoire allouée à l'instance de nœud. via le drapeau --max_old_space_size .

Une chose qui m'inquiète à propos de cette fonctionnalité est la création de schémas. Si nous n'avons pas tous les articles disponibles pour que gatsby puisse créer un schéma, nos requêtes généreront des erreurs. Ce serait vraiment bien s'il y avait un moyen de transmettre des schémas à gatsby, ou au moins de fournir des entités factices lors de la construction pour démontrer les différentes formes qu'ils peuvent prendre.

J'envisage d'utiliser Gatsby pour créer l'interface utilisateur d'un site de contenu avec plus de 5000 éléments, la plupart avec des relations interconnectées les uns avec les autres. Les données proviendront d'un CMS basé sur une base de données.

L'avantage d'utiliser Gatsby par rapport à un site React standard basé sur l'API est que je passerais une fraction du temps à créer et à maintenir l'API de données et le système de gestion d'état qui charge les données distantes et les stocke. (Puisque je prévois de déployer cette application pour plusieurs sites de taille similaire, cela semble être un avantage très précieux.)

L'inconvénient de l'utilisation de Gatsby dans ce cas serait le fait que l'ensemble du site devrait être reconstruit, même pour la mise à jour de contenu la plus insignifiante. Vous avez oublié d'ajouter une virgule? Reconstruisez les 5000 pages! Qui sait même combien de temps cela prendrait? C'est encore plus un problème lorsque l'on considère l'expérience des utilisateurs du CMS - ils ont l'habitude de voir les modifications apparaître sur le site immédiatement après les avoir enregistrées. Avec Gatsby, nous attendons quelques minutes d'attente (au moins) avant que le changement n'apparaisse.

S'il y avait un moyen de déclencher des builds pour un sous-ensemble de pages, cela ferait de Gatsby le choix clair et définitif. En ce moment, cependant, c'est une vente difficile.

BTW, j'ai beaucoup travaillé sur l'amélioration des vitesses pour les versions de site plus grandes pour la v2. Sur la dernière version bêta de la v2, vous pourrez peut-être créer 5000 pages en <1h30. Il y aura d'autres améliorations de vitesse à venir.

C'est incroyable @KyleAMathews! J'ai vraiment hâte d'y être! Faites-moi savoir si vous souhaitez tester contre un blog riche en images

@KyleAMathews 5K c'est bien mais nous avons besoin de 1M 😉

Si nous voulons compiler des parties du site séparément, nous pouvons définir des indicateurs lors de la construction afin que gatsby-node sache uniquement pour générer les parties du site spécifiées. Nous pourrions ensuite rajouter les fichiers statiques précédemment générés. Cela fonctionne pour nous tant que nous établissons un lien vers les fichiers précédemment générés avec un <a href> par opposition à un <Link to > .

Je me demande si nous pouvons faire fonctionner <Link to> lors de la liaison à des fichiers précédemment générés si nous fusionnons certains des data.json précédents au moment de la construction. Je regarde cela un peu plus pour le moment.

Je n'ai pas de souci avec le temps de construction mais plus avec le volume de fichiers statiques que j'ai besoin de télécharger pour toute mise à jour, nous avons lancé un grand portefeuille visuel avec Gatsby et le site statique à télécharger dépasse 150 Mo
Surtout des images.
Cela rend le site indisponible environ 40 minutes lors d'une mise à jour
La disponibilité pour reconstruire une partie du site est certainement une fonctionnalité qui dynamiserait Gatsby.
Je prévois d'utiliser Gatsby pour un nouveau site mais je vais diviser le site en une partie statique et dynamique en utilisant un CMS php traditionnel pour la partie news.

@rbmedia, vous voudrez peut-être envisager un hôte qui effectue la commutation de déploiement comme Netlify afin que votre site actuel reste en cours d'exécution jusqu'à ce que votre nouvelle version soit prête.

Merci Matt, je vais y réfléchir!
J'ai construit des sites Web d'actualités avec Drupal dans le passé, toute mise à jour devait être en ligne dans un court laps de temps (moins de 2 minutes). J'adorerais utiliser Gatsby à l'avenir pour ce genre de sites.

Des nouvelles à ce sujet? Nous prévoyons un site avec environ 100000 pages et des versions incrémentielles seraient géniales.

créer un autre chemin comme dossier de page statique par défaut, pas '/ public'.
Après avoir exécuté gatsby build, copiez le ../public/* dans le chemin par défaut.

Hiya!

Ce problème est devenu silencieux. Silencieux effrayant. 👻

Nous recevons beaucoup de problèmes, donc nous clôturons actuellement les problèmes après 30 jours d'inactivité. Cela fait au moins 20 jours depuis la dernière mise à jour ici.

Si nous avons manqué ce problème ou si vous souhaitez le garder ouvert, veuillez répondre ici. Vous pouvez également ajouter l'étiquette «non périmé» pour garder ce problème ouvert!

Merci de faire partie de la communauté Gatsby! 💪💜

Je ne pense toujours pas que cela soit corrigé / pris en charge dans Gatsby. Des nouvelles @ TeamGatsby?

c'est un problème de longue date car il est vraiment difficile à résoudre sans y penser beaucoup. @Moocar a un problème ouvert pour au moins nous faire un pas dans la bonne direction.

Gatsby suit-il actuellement quels nœuds GraphQL sont récupérés sur une page donnée? Si tel est le cas, il semblerait viable d'ajouter des reconstructions incrémentielles en fonction des modifications apportées aux données. C'est la moitié du travail, non?

L'autre travail consiste à fournir des plugins sources avec un cache et à encourager les développeurs de plugins à ne récupérer que les données modifiées lorsque cela est possible. Dans de nombreux cas, c'est trivial.

@coreyward Oui, Gatsby suit chaque nœud renvoyé pour une requête (via page-dependency-resolver.js ). C'est ce qui permet à gatsby develop de ne réexécuter les requêtes que pour les données modifiées. Nous ne sauvegardons pas actuellement ces informations sur le disque, elles ne sont donc pas encore utilisées pour gatsby build , mais c'est définitivement le plan.

Je sais que pour notre équipe, ce sera la décision de ne pas utiliser Gatsby pour la reconstruction de notre site phare en 2019. J'espère vraiment qu'il pourra être publié ou du moins être à l'horizon alors que nous commençons à construire. Nous soutenons des centaines d'auteurs Web qui éditent diverses parties du site tout au long de la journée de travail. Lorsqu'ils appuient sur Enregistrer, ils s'attendent à peu près à ce que le contenu soit mis à jour. Il n'est pas rare qu'ils reviennent simplement pour corriger une virgule ou changer la date sur le message.

@mattbloomfield, nous avons plus de clients intéressés par cela, nous avons donc cela en haut de la liste des priorités.

nous implémentons gatsby avec un backend drupal 8 utilisant le plugin gatsby-source-graphql, et les performances ne sont pas un problème jusqu'à présent, avec ~ 4000 pages construites en moins de 30 secondes. nous extrayons toutes les données dans gatsby-node au lieu d'exécuter des milliers de StaticQuerys et de contourner le traitement d'image pour le moment.

''
succès exécuter des requêtes graphql - 3,088 s - 4008/4008 1311,56 requêtes / seconde
succès écrire les données de la page - 0,070 s
succès écrire les données de redirection - 0,001 s
succès Build manifest et icônes associées - 0,117 s
succès onPostBootstrap - 0,127 s

info bootstrap terminé - 15,751 s

succès Création de bundles JavaScript et CSS pour la production - 3,361 s
réussite Création de HTML statique pour les pages - 6,906 s - 4006/4006 609,25 pages / seconde
info Construction terminée en 26.047 sec

J'évalue actuellement l'utilisation de Gatsby pour accélérer un ancien site Rails 3.x hébergé par Heroku, lent comme la mélasse. Il a environ 1 million de pages, donc les versions incrémentielles sont la seule façon de fonctionner. La plupart des pages ne changent pas, donc les rendre statiques semble être une énorme victoire, mais de nouvelles pages sont constamment ajoutées et certaines anciennes pages sont modifiées. Les utilisateurs s'attendent à voir les changements en quelques secondes. Mon espoir était d'ajouter juste assez de code à l'application Rails pour en faire un serveur d'API JSON et de générer une nouvelle interface avec Gatsby, avec des actifs statiques hébergés quelque part comme Netlify ou S3.

Je pensais que je serais capable de faire quelque chose comme exécuter une version incrémentielle de Gatsby via un travailleur de file d'attente. Le serveur de l'API Rails sait quand une page est mise à jour, donc il créerait un `` travail de page de mise à jour '' en utilisant le page_id (une clé dans la base de données postgres), et le worker le transmettrait à Gatsby avec une var ENV avec quelque chose comme PAGE_ID=1235 gatsby build . J'utiliserais cette variable ENV dans createPages () pour rechercher juste ce qui est nécessaire pour cette page et la construire. Le ou les fichiers de sortie résultants seraient transférés vers l'hôte statique (j'espère qu'il y a un hook de construction pour cela). Si aucune variable PAGE_ID n'est définie, toutes les pages seront créées comme d'habitude.

Si une page est supprimée, l'API Rails créerait un travail qui supprime les actifs directement de l'hôte statique, ou peut-être que Gatsby a besoin de quelque chose, donc je l'exécuterais toujours avec une variable ENV différente. (Je pense que j'aurais besoin du chemin de la page au minimum).

Suis-je en train d'aboyer le mauvais arbre en pensant que Gatsby est compatible avec ce genre de projet? Merci pour toute aide.

Nous avons une version alpha. Ce ne sont pas encore des versions incrémentielles, mais au moins la voie à suivre.
vous pouvez l'utiliser en installant npm install --save gatsby@per-page-manifest

Plus d'informations:
https://github.com/gatsbyjs/gatsby/pull/13004

@mpoisot pour le moment, la

cc @KyleAMathews @Moocar pour donner une meilleure explication à ce sujet.

Pinging ceci, car cela fait quelques mois depuis la dernière mise à jour et cela semble être le lieu d'action. Je vois que la décomposition de la page-data.json a été dans, et je l'utilise.

Existe-t-il un ensemble d'exigences et de tâches plus concrètes pour faire avancer cela? Je comprends que c'est un gros problème, mais cela aide toujours s'il est visiblement décomposé en problèmes plus petits qui peuvent montrer des progrès et de la traction.

@wardpeet @Moocar Je ne sais pas qui est la personne / liste la plus appropriée pour cingler là-dessus, mais je vois que vous êtes tous les deux les derniers actifs du projet ici. Des mises à jour concernant l'objectif principal de ce ticket?

Avoir une bonne conversation avec @KyleAMathews sur les versions incrémentielles et comment elles pourraient être livrées https://twitter.com/dominicfallows/status/1169152367964643328?s=19

Avoir une bonne conversation avec @KyleAMathews sur les versions incrémentielles et comment elles pourraient être livrées https://twitter.com/dominicfallows/status/1169152367964643328?s=19

TLDR;

@KyleAMathews a confirmé que Gatsby travaillait sur les fonctionnalités de construction incrémentielle hébergées par Gastsby Cloud.

La version "Gatsby Enterprise" auto-hébergée / sur site, avec des builds incrémentiels, est possible, mais ils ne travaillent pas encore dessus ...

Dominic Fallows - 4 septembre - La plupart des fournisseurs que nous choisissons proposent une option autogérée / sur site, comme le fait Gatsby OSS. Nous les payons volontiers, comme nous le ferions pour une solution Gatsby Enterprise Cloud sur site de votre part.

Kyle Mathews - 4 septembre - oui, bien sûr - nous avons un chemin assez clair pour prendre en charge les versions onprem de ce que nous faisons - c'est tout Kubernetes donc cela devrait être possible - mais onprem ajoute beaucoup de frais généraux lorsque nous ne faisons que travailler initialement sur l'expédition de quelque chose qui fonctionne 😅

Dominic Fallows - 4 septembre - Voilà une excellente nouvelle à entendre! Désolé si j'ai manqué ce qui a été discuté ailleurs, mais cette feuille de route sur le premier serait très utile pour les entreprises et les développeurs d'avoir vue.

Kyle Mathews - 4 septembre - C'est assez loin maintenant que je ne pourrais pas donner de chronologie. Certainement pas cette année et je ne voudrais pas non plus promettre l'année prochaine. Dépend de la rapidité avec laquelle nous pouvons augmenter les revenus et de notre équipe d'ingénierie

C'est dommage car cela bloque l'utilisation de Gatsby comme outil pour les éditeurs où nous parlons de millions de pages canoniques et d'autres pages identiques ou indexées.

Ne serait-il pas logique d '«éjecter» un tel cas d'utilisation en tant que projet séparé utilisant les mêmes concepts / noyau?

Fonction Make or Break pour les décisions 2020. Semble être un bon endroit pour investir tout cet argent VC 😀

Gatsby fait beaucoup de choses correctement, mais les longs temps de construction le rendent absolument inutilisable dans les grands projets: / Nous avons discuté de l'abandon du framework cette semaine juste à cause de cela.
Veuillez accélérer la construction!

D'accord avec ci-dessus! Gatsby est soit intégré dans une solution de blogage rapide et facile, soit implémente des builds incrémentiels / plus rapides et devient prêt pour l'entreprise.

Absolument correct; se heurter à cela encore et encore sur des projets plus importants. Sans constructions incrémentielles, Gatsby n'est pas une option.

Les builds incrémentiels sur Gatsby Cloud corrigent ces problèmes. Vous pouvez vous inscrire à la bêta privée ici https://www.gatsbyjs.com/builds-beta/

Rien à ce sujet ne semble suggérer qu'il prend en charge les versions incrémentielles - juste qu'il a les "temps de construction les plus rapides pour les sites Gatsby".

Je serais préoccupé par l'implication selon laquelle les versions incrémentielles ne seraient disponibles que sur un service Gatsby hébergé plutôt que disponibles pour être utilisées de manière autonome.

Je vois ce que tu veux dire @dwightwatson, il n'y a rien sur le site Web qui dit que c'est "incrémental". Au Gatsby Days London, ils ont fait des démonstrations de builds et c'était définitivement des builds incrémentiels. Je ne sais pas comment cela se fait et si cela fera partie du package Gatsby ou si ce sera simplement un service qu'ils fournissent.

Les investisseurs doivent récupérer leur argent d'une manière ou d'une autre. 🙄

essayer de créer un très grand site Web de plus de 140 000 pages

gatsby build c'est plutôt bien ... mais faire le déploiement c'est pénible (zeit.co)

Je ne sais pas comment ajouter une étiquette à cela, mais je considère cela comme un problème.

@gomflo y a-t-il un moyen de créer votre site? Il y a peut-être des fruits faciles à résoudre pour améliorer les temps de construction :) Aucune promesse.

Rien à ce sujet ne semble suggérer qu'il prend en charge les versions incrémentielles - juste qu'il a les "temps de construction les plus rapides pour les sites Gatsby".

Je serais préoccupé par l'implication selon laquelle les versions incrémentielles ne seraient disponibles que sur un service Gatsby hébergé plutôt que disponibles pour être utilisées de manière autonome.

re this ^: Si mon dépôt gatsby est dans gitlab et non github, pourrai-je utiliser les fonctionnalités cloud / build de gatsby?

J'aurais peut-être mentionné cela avant, mais en ce qui concerne le problème / fonctionnalité d'origine. Pour les éditeurs, Gatsby aura du sens si nous pouvions déclencher la seule génération de nouvelles pages et peut-être mettre à jour les index. Presque aucun éditeur ne se soucierait de mettre à jour les anciennes pages canoniques.

Alors aurons-nous une mise à jour partielle autonome ou aucune chance? Peut-être existe-t-il un autre moyen de mettre à jour seulement quelques pages et de ne pas reconstruire l'ensemble du projet?

Je voulais juste mettre à jour que mon équipe est sur le point de publier un PR dans le repo Gatsby qui, selon nous, permet des builds incrémentiels. Nous prenons juste le temps d'écrire un bon PR et de resserrer le code, mais je mettrai à jour ici lorsque nous aurons terminé (dans la semaine prochaine environ).

Je voulais juste mettre à jour que mon équipe est sur le point de publier un PR dans le repo Gatsby qui, selon nous, permet des builds incrémentiels. Nous prenons juste le temps d'écrire un bon PR et de resserrer le code, mais je mettrai à jour ici lorsque nous aurons terminé (dans la semaine prochaine environ).

Voici le PR https://github.com/gatsbyjs/gatsby/pull/20785

Mise à jour supplémentaire du PR: https://github.com/gatsbyjs/gatsby/pull/20785#issuecomment -579355927

Nouveau PR, axé sur les modifications incrémentielles des données https://github.com/gatsbyjs/gatsby/pull/21523

Avec la fusion de # 21523 et les versions incrémentielles disponibles dans Gatsby Cloud, je pense que ce problème est résolu. Il ne prend pas en charge tous les flux de travail, mais je vais le fermer pour le moment et il vaudrait peut-être mieux ouvrir un nouveau numéro à l'avenir pour des efforts futurs si nécessaire.

Doit-il vraiment être fermé? L'optimisation n'était que cela - une optimisation. Ce n'était pas vraiment des versions incrémentielles. De plus, tout ce qui est disponible via Gatsby Cloud n'est pas disponible via l'utilisation du package public. Pour l'intention spécifique de ce ticket, rien n'a été résolu.

Doit-il vraiment être fermé?

Basé sur https://github.com/gatsbyjs/gatsby/issues/5496#issuecomment -641005662, je ne pense pas que ce problème devrait rester fermé, et je ne comprends pas pourquoi l'étiquette not stale été supprimée .

Quelqu'un ici a-t-il essayé, ou sait-il s'il est possible, de modifier la configuration du webpack de GatsbyJS pour produire simultanément à la fois un aperçu de développement et une version de production avec «gatsby develop»? (Il peut en résulter des «builds incrémentiels» avec le coût de l'exécution permanente du serveur de développement.)