No es algo que Gatsby haga en este momento, pero es algo que la gente ha pedido. Se ha trabajado en la versión 2 para mejorar el rendimiento en sitios más grandes, pero aún no hay una fecha de lanzamiento para eso.

@ m-allanson ¿hay alguna discusión / problema sobre cómo manejar esto? No lo vi en el enlace que enumeraste. Tengo curiosidad por escuchar conversaciones sobre cómo manejar esto en un host como Netlify y usar un CMS como Wordpress / Drupal que actualmente requiere muchas solicitudes HTTP durante la compilación.

AFAIK, no podría usar compilaciones incrementales en netlify porque los directorios .cache y public no se conservan entre compilaciones, por lo que siempre será una compilación limpia

Es bueno saberlo. Estoy lanzando un montón de ideas que no están bien pensadas. Entonces, incluso si pudiéramos eliminar la necesidad de solicitudes HTTP, aún debemos asegurarnos de que la herramienta de compilación pueda hacer referencia a los directorios .cache y público, lo que elimina muchos de los hosts que bajan la barra de entrada.

Otro caso de uso para la construcción incremental es cuando tiene un sitio muy grande que desea construir en partes. Estaba obteniendo un "error de memoria acumulada" al crear ~ 5000 páginas a la vez.

Planeamos que nuestro sitio sea muy grande, por lo que estamos probando Gatsby a escalas más grandes. Hemos intentado hacer algo como esto path: './src/pages/${subPath}', donde subPath es process.argv[3] . Esto funciona muy bien cuando hospedamos partes de nuestro sitio con gatsby develop . También evita los problemas con el montón de memoria cuando se usa gatsby build para un sitio de más de 5k páginas. Para que realmente sea una solución, probablemente dependa de la capacidad de especificar un subdirectorio de salida dentro de la carpeta pública: https://github.com/gatsbyjs/gatsby/pull/4756

¿Qué pasa si se utiliza otro enfoque para lograr el mismo objetivo? Quería presentarles una idea y ver qué piensa la gente. Digamos que tiene un sitio web de 5k páginas. Las páginas iniciales se generarían de forma estática, pero cada página tendrá un subcomponente que se cargará sobre el contenido estático con el mismo contenido que se lee de los archivos json estáticos. De esta manera, si un usuario desea actualizar una página en el CMS a la mitad del día, puede realizar la actualización y solo ese archivo json estático se regeneraría y se implementaría en una CDN. Luego, puede regenerar todo el sitio tal vez una vez al día como un proceso nocturno. El contenido estático de SEO puede no ser el más actualizado durante el día, pero no lo veo como un gran problema. Solo se actualizará durante el proceso nocturno.

@robertschneiderman también nos hemos topado con el problema de la memoria. Estamos más cerca de las 1500 páginas, pero una cantidad increíble de imágenes (blog de diseño). Hemos desactivado los mapas de origen y evitamos que la compilación descargue archivos de imagen, pero finalmente tuvimos que editar el comando de compilación para aumentar la memoria asignada a la instancia del nodo. a través de la bandera --max_old_space_size .

Una cosa que me preocupa de esta función es la creación de esquemas. Si no tenemos todas las publicaciones disponibles para que gatsby construya un esquema, nuestras consultas arrojarán errores. Sería realmente bueno si hubiera una forma de pasar esquemas a gatsby, o al menos proporcionar entidades ficticias durante la compilación para demostrar las diferentes formas que pueden tomar.

Estoy considerando usar Gatsby para crear la interfaz de usuario de un sitio de contenido con más de 5000 elementos, la mayoría con relaciones interconectadas entre sí. Los datos provendrán de un CMS basado en bases de datos.

El beneficio de usar Gatsby en un sitio React estándar impulsado por API es que dedicaría una fracción del tiempo a construir y mantener la API de datos y el sistema de administración de estado que carga los datos remotos y los almacena. (Dado que planeo implementar esta aplicación para varios sitios de tamaño similar, esto parece un beneficio muy valioso).

La desventaja de usar Gatsby en este caso sería el hecho de que todo el sitio tendría que ser reconstruido incluso para la actualización de contenido más insignificante. ¿Olvidaste agregar una coma? ¡Reconstruye las 5000 páginas! ¿Quién sabe cuánto tiempo tomaría eso? Esto es aún más problemático cuando se considera la experiencia de los usuarios de CMS: están acostumbrados a ver que los cambios aparecen en el sitio inmediatamente después de guardarlos. Con Gatsby, estamos esperando unos minutos (al menos) antes de que aparezca el cambio.

Si hubiera una forma de activar compilaciones para un subconjunto de páginas, Gatsby sería la opción clara y definitiva. Sin embargo, en este momento es difícil de vender.

Por cierto, he estado trabajando mucho para mejorar las velocidades de las compilaciones de sitios más grandes para v2. En la última versión beta v2, es posible que pueda crear 5000 páginas en <1:30. Habrá más mejoras de velocidad en camino.

¡Eso es increíble @KyleAMathews! ¡Definitivamente espero con ansias eso! Avísame si quieres probar con un blog con muchas imágenes

@KyleAMathews 5K es bueno pero necesitamos 1M 😉

Si queremos compilar partes del sitio por separado, podemos establecer marcas en la compilación para que gatsby-node sepa solo generar las partes del sitio especificadas. A continuación, podríamos volver a agregar los archivos estáticos generados anteriormente . Esto funciona para nosotros siempre que nos vinculemos a los archivos generados previamente con un <a href> básico en lugar de un <Link to > .

Me pregunto si podemos hacer que <Link to> funcione al vincular a archivos generados previamente si fusionamos algunos de los data.json en el momento de la compilación. Mirando eso un poco más en este momento.

No me preocupo por el tiempo de compilación, pero más por el volumen de archivos estáticos que necesito cargar para cualquier actualización, lanzamos un gran portafolio visual con Gatsby y el sitio estático para cargar es de más de 150 MB.
Mayormente imágenes.
Esto hace que el sitio no esté disponible alrededor de 40 minutos durante una actualización.
La disponibilidad para reconstruir una parte del sitio es definitivamente una característica que impulsaría a Gatsby.
Planeo usar Gatsby para un nuevo sitio, pero dividiré el sitio en una parte estática y dinámica usando un CMS php tradicional para la parte de noticias.

@rbmedia, es posible que desee considerar un host que realice cambios de implementación como Netlify para que su sitio actual siga funcionando hasta que su nueva versión esté lista.

Gracias Matt, lo consideraré!
Construí algunos sitios web de noticias con Drupal en el pasado, cualquier actualización tenía que estar en línea en un breve lapso de tiempo (menos de 2 minutos). Me encantaría usar Gatsby en el futuro para este tipo de sitios.

¿Alguna novedad sobre este asunto? Planeamos un sitio con alrededor de 100k páginas y las compilaciones incrementales serían increíbles.

haga otra ruta como carpeta de página estática predeterminada, no '/ public'.
Después de ejecutar gatsby build, copie ../public/* a la ruta predeterminada.

Hola!

Este tema se ha silenciado. Silencio espeluznante. 👻

Tenemos muchos problemas, por lo que actualmente los cerramos después de 30 días de inactividad. Han pasado al menos 20 días desde la última actualización aquí.

Si no detectamos este problema o si desea mantenerlo abierto, responda aquí. ¡También puede agregar la etiqueta "no obsoleto" para mantener este problema abierto!

¡Gracias por ser parte de la comunidad de Gatsby! 💪💜

Todavía no creo que esto esté arreglado / soportado en Gatsby. ¿Alguna noticia @ TeamGatsby?

es un problema de larga data porque es realmente difícil de solucionar sin pensar mucho en ello. @Moocar tiene un problema abierto para al menos darnos un paso en la dirección correcta.

¿Gatsby actualmente rastrea qué nodos GraphQL se recuperan en una página determinada? Si es así, parecería viable agregar reconstrucciones incrementales basadas en cambios en los datos. Eso es la mitad del trabajo, ¿no?

La otra parte del trabajo es proporcionar complementos de origen con un caché y alentar a los desarrolladores de complementos a obtener solo los datos modificados cuando sea posible. En muchos casos, esto es trivial.

@coreyward Sí, Gatsby rastrea cada nodo que se devuelve para una consulta (a través de page-dependency-resolver.js ). Es lo que potencia la capacidad de gatsby develop volver a ejecutar consultas solo para datos modificados. Actualmente no guardamos esa información en el disco, por lo que aún no se usa para gatsby build pero ese es definitivamente el plan.

Sé que para nuestro equipo esta será la decisión de ir / no ir en contra de usar Gatsby para nuestra reconstrucción de 2019 de nuestro sitio insignia. Realmente espero que pueda ser lanzado o al menos estar en el horizonte mientras comenzamos a construir. Apoyamos a cientos de autores web que editan varias partes del sitio durante la jornada laboral. Cuando presionan guardar, esperan que el contenido se actualice. No es raro que regresen solo para arreglar una coma o cambiar la fecha en la publicación.

@mattbloomfield tenemos más clientes interesados ​​en esto, así que lo tenemos en lo alto de la lista de prioridades.

estamos implementando gatsby con un backend de drupal 8 usando el complemento gatsby-source-graphql, y el rendimiento no es un problema hasta ahora, con ~ 4000 páginas creadas en <30 segundos. estamos extrayendo todos los datos en gatsby-node en lugar de ejecutar miles de StaticQuerys y omitir el procesamiento de imágenes por ahora.

''
ejecutar correctamente las consultas graphql - 3.088 s - 4008/4008 1311.56 consultas / segundo
éxito escribir datos de la página - 0.070 s
éxito escribir datos de redireccionamiento - 0.001 s
Manifiesto de compilación de éxito e íconos relacionados - 0.117 s
éxito enPostBootstrap - 0.127 s

info bootstrap terminado - 15.751 s

Éxito en la creación de paquetes de producción de JavaScript y CSS - 3.361 s
éxito Construyendo HTML estático para páginas - 6.906 s - 4006/4006 609.25 páginas / segundo
info Terminado de construir en 26.047 seg.

Actualmente estoy evaluando el uso de Gatsby para acelerar un antiguo sitio Rails 3.x alojado en Heroku que es lento como la melaza. Tiene alrededor de 1 millón de páginas, por lo que las compilaciones incrementales son la única forma en que funcionaría. La mayoría de las páginas no cambian, por lo que hacerlas estáticas se siente como una gran ganancia, pero constantemente se agregan nuevas páginas y algunas páginas antiguas se editan. Los usuarios esperan ver los cambios en segundos. Mi esperanza era agregar el código suficiente a la aplicación Rails para convertirla en un servidor API JSON y generar una nueva interfaz con Gatsby, con activos estáticos alojados en algún lugar como Netlify o S3.

Estaba pensando que podría hacer algo como ejecutar una compilación incremental de Gatsby a través de un trabajador de cola de trabajos. El servidor de la API de Rails sabe cuándo se actualiza una página, por lo que crearía un 'trabajo de actualización de página' usando page_id (una clave en la base de datos de postgres), y el trabajador pasaría eso a Gatsby con una var ENV con algo como PAGE_ID=1235 gatsby build . Usaría esa var ENV dentro de createPages () para buscar lo que se necesita para esa página y compilarlo. Los archivos de salida resultantes se transferirían al host estático (espero que haya un gancho de compilación para eso). Si no se establece ninguna var PAGE_ID, se construirían todas las páginas como de costumbre.

Si se elimina una página, la API de Rails crearía un trabajo que eliminaría los activos directamente del host estático, o tal vez se necesita algo de Gatsby, por lo que aún lo ejecutaría con una variable ENV diferente. (Creo que necesitaría la ruta de la página como mínimo).

¿Estoy ladrando al árbol equivocado pensando que Gatsby es compatible con este tipo de proyecto? Gracias por cualquier ayuda.

Tenemos una versión alfa. Aún no se trata de compilaciones incrementales, pero al menos el camino a seguir.
puedes usarlo instalando npm install --save gatsby@per-page-manifest

Más información:
https://github.com/gatsbyjs/gatsby/pull/13004

@mpoisot, por ahora, la creación de páginas aún no funciona. No estoy seguro de cuál es el período de tiempo que está buscando para este proyecto. Si las consultas son ligeras, gatsby podría encajar bien en su sitio incluso sin compilaciones incrementales.

cc @KyleAMathews @Moocar para dar una mejor explicación de esto.

Haciendo ping a esto, ya que han pasado unos meses desde la última actualización y parece ser el lugar de acción. Veo que el desglose de page-data.json se ha producido y lo he estado usando.

¿Existe un conjunto más concreto de requisitos y tareas que impulsen esto? Entiendo que es un gran problema, pero siempre ayuda si está visiblemente dividido en problemas más pequeños que pueden mostrar progreso y tracción.

@wardpeet @Moocar No estoy seguro de quién es la persona / lista más apropiada para hacer ping en esto, pero veo que ambos son los últimos activos del proyecto aquí. ¿Alguna actualización sobre el objetivo principal de este ticket?

Tener una buena conversación con @KyleAMathews sobre compilaciones incrementales y cómo podrían entregarse https://twitter.com/dominicfallows/status/1169152367964643328?s=19

Tener una buena conversación con @KyleAMathews sobre compilaciones incrementales y cómo podrían entregarse https://twitter.com/dominicfallows/status/1169152367964643328?s=19

TLDR;

@KyleAMathews confirmó que Gatsby está trabajando en las funciones de compilación incremental alojadas en Gastsby Cloud.

La versión "Gatsby Enterprise" autohospedada / local, con compilaciones incrementales, es posible, pero todavía no están trabajando en ella ...

Dominic Fallows - 4 de septiembre - La mayoría de los proveedores que elegimos ofrecen una opción autogestionada / local, como lo hace Gatsby OSS. Con mucho gusto pagamos por ellos, como lo haríamos con una solución local de Gatsby Enterprise Cloud de usted.

Kyle Mathews - 4 de septiembre - sí, seguro, tenemos un camino bastante claro para admitir versiones originales de lo que estamos haciendo; todo es Kubernetes, por lo que debería ser posible, pero onprem agrega mucha sobrecarga cuando inicialmente solo estamos trabajando sobre enviar algo que funcione 😅

Dominic Fallows - 4 de septiembre - ¡Es una gran noticia para escuchar! Perdón si me he perdido lo que se discutió en otra parte, pero esa hoja de ruta en primer lugar sería muy útil para las empresas y los desarrolladores.

Kyle Mathews - 4 de septiembre - Está lo suficientemente lejos en este momento como para no poder dar una línea de tiempo. Definitivamente no este año y tampoco querría prometer el próximo año. Depende de qué tan rápido podamos escalar los ingresos y nuestro equipo de ingeniería

Es una pena ya que bloquea el uso de Gatsby como herramienta para las editoriales donde hablamos de millones de páginas canónicas y otras iguales o indexadas.

¿No tendría sentido "expulsar" tal caso de uso como un proyecto separado usando los mismos conceptos / núcleo?

Función de hacer o deshacer para las decisiones de 2020. Parece ser un buen lugar para invertir todo ese dinero VC 😀

Gatsby hace muchas cosas bien, pero los largos tiempos de compilación lo hacen absolutamente inutilizable en proyectos más grandes: / Hablamos de dejar el marco esta semana solo por eso.
¡Haz que la construcción sea más rápida!

¡De acuerdo con lo anterior! Gatsby se convierte en una solución de blogs rápida y fácil o implementa compilaciones incrementales / más rápidas y se vuelve listo para la empresa.

Absolutamente correcto; chocando contra esto una y otra vez en proyectos más grandes. Sin compilaciones incrementales, Gatsby no es una opción.

Las compilaciones incrementales en Gatsby Cloud solucionan estos problemas. Puede registrarse para la versión beta privada aquí https://www.gatsbyjs.com/builds-beta/

Sin embargo, nada de eso parece sugerir que admita compilaciones incrementales, solo que tiene los "tiempos de compilación más rápidos para los sitios de Gatsby".

Me preocuparía la implicación de que las compilaciones incrementales solo estarían disponibles en un servicio alojado de Gatsby en lugar de estar disponibles para usarse de forma independiente.

Entiendo lo que quieres decir @dwightwatson, no hay nada en el sitio web que diga que es "incremental". En Gatsby Days London hicieron demostraciones de compilaciones y definitivamente fueron compilaciones incrementales. Sin embargo, no estoy seguro de cómo se hace y si será parte del paquete Gatsby o si solo será un servicio que brinden.

Los inversores deben recuperar su dinero de alguna manera. 🙄

tratando de crear un sitio web muy grande con más de 140.000 páginas

gatsby build es algo bueno ... pero hacer la implementación es doloroso (zeit.co)

No estoy seguro de cómo agregar una etiqueta a esto, pero lo dejo como un problema.

@gomflo, ¿hay alguna manera de que pueda construir su sitio? Puede que haya que resolver algunas cosas fáciles para mejorar los tiempos de construcción :) Sin promesas

Sin embargo, nada de eso parece sugerir que admita compilaciones incrementales, solo que tiene los "tiempos de compilación más rápidos para los sitios de Gatsby".

Me preocuparía la implicación de que las compilaciones incrementales solo estarían disponibles en un servicio alojado de Gatsby en lugar de estar disponibles para usarse de forma independiente.

¿Es esto ^: si mi repositorio de gatsby está en gitlab y no en github, podré usar las funciones de gatsby cloud / build?

Podría haber mencionado eso antes, pero con respecto al problema / característica original. Para los editores, Gatsby tendría sentido si pudiéramos activar la única generación de páginas nuevas y quizás actualizar a índices. Casi ningún editor se preocuparía por actualizar las páginas canónicas antiguas.

Entonces, ¿tendremos una actualización parcial independiente o ninguna posibilidad? ¿Quizás hay otra forma de actualizar solo unas pocas páginas y no reconstruir todo el proyecto?

Solo quería actualizar que mi equipo está cerca de publicar un PR en el repositorio de Gatsby que creemos que permite compilaciones incrementales. Solo nos estamos tomando un tiempo para escribir un buen relaciones públicas y ajustar el código, pero lo actualizaré aquí cuando terminemos (en la próxima semana).

Solo quería actualizar que mi equipo está cerca de publicar un PR en el repositorio de Gatsby que creemos que permite compilaciones incrementales. Solo nos estamos tomando un tiempo para escribir un buen relaciones públicas y ajustar el código, pero lo actualizaré aquí cuando terminemos (en la próxima semana).

Aquí está el PR https://github.com/gatsbyjs/gatsby/pull/20785

Actualización adicional del PR: https://github.com/gatsbyjs/gatsby/pull/20785#issuecomment -579355927

Nuevo PR, centrándose en cambios de datos incrementales https://github.com/gatsbyjs/gatsby/pull/21523

Con # 21523 fusionado y compilaciones incrementales disponibles en Gatsby Cloud, creo que este problema está resuelto. No es compatible con todos los flujos de trabajo, pero voy a cerrar esto por ahora y puede que sea mejor abrir un nuevo problema en el futuro para futuros esfuerzos si es necesario.

¿Debería estar realmente cerrado? La optimización fue solo eso: una optimización. No fueron realmente construcciones incrementales. Además de eso, lo que esté disponible a través de Gatsby Cloud no está disponible mediante el uso del paquete público. Para la intención específica de este ticket, no se ha resuelto nada.

¿Debería estar realmente cerrado?

Basado en https://github.com/gatsbyjs/gatsby/issues/5496#issuecomment -641005662, no creo que este problema deba permanecer cerrado y no entiendo por qué se eliminó la etiqueta not stale .

¿Alguien ha intentado, o sabe si es posible, modificar la configuración del paquete web de GatsbyJS para producir simultáneamente tanto la vista previa del desarrollo como la versión de producción con "gatsby desarrollar"? (Posiblemente resulten "compilaciones incrementales" con el costo de ejecutar el servidor de desarrollo para siempre).