Não é algo que Gatsby faz no momento, mas é algo que as pessoas pediram. Houve trabalho na versão 2 para melhorar o desempenho em sites maiores, mas ainda não há data de lançamento para isso.

@ m-allanson há uma discussão / problema sobre como lidar com isso? Não o vi no link que você listou. Estou curioso para ouvir conversas sobre como lidar com isso em um host como o Netlify e usando um CMS como o Wordpress / Drupal que atualmente requer muitas solicitações HTTP durante a compilação.

AFAIK você não seria capaz de usar compilações incrementais no netlify porque os diretórios .cache e public não são preservados entre as compilações, então sempre fará uma compilação limpa

É bom saber disso. Estou lançando uma tonelada de ideias que não foram bem pensadas. Portanto, mesmo que pudéssemos eliminar a necessidade de solicitações HTTP, ainda precisamos ter certeza de que os diretórios .cache e públicos podem ser referenciados pela ferramenta de construção que elimina muitos dos hosts que reduzem a barra de entrada.

Outro caso de uso para construção incremental é quando você tem um site muito grande que deseja construir em partes. Eu estava recebendo "erro de pilha sem memória" ao construir ~ 5k páginas de uma vez.

Planejamos tornar nosso site muito grande, então estamos testando Gatsby em escalas maiores. Tentamos fazer algo assim path: './src/pages/${subPath}', onde o subPath é process.argv[3] . Isso funciona bem quando hospedamos partes do nosso site com gatsby develop . Ele também contorna os problemas com o heap de memória ao usar gatsby build para um site de página de 5k +. Para ser realmente uma solução, provavelmente dependeria da capacidade de especificar um subdiretório de saída dentro da pasta pública: https://github.com/gatsbyjs/gatsby/pull/4756

e se outra abordagem for usada para atingir o mesmo objetivo. Queria passar uma ideia de vocês e ver o que as pessoas pensam. Digamos que você tenha um site de 5 mil páginas. As páginas iniciais seriam geradas estaticamente, mas cada página terá um subcomponente que carregará na parte superior do conteúdo estático com o mesmo conteúdo que é lido dos arquivos json estáticos. Dessa forma, se um usuário quiser atualizar uma página no CMS no meio do dia, ele pode fazer a atualização e apenas aquele arquivo json estático seria regenerado e implantado em um CDN. Em seguida, você pode apenas regenerar todo o site, talvez uma vez por dia, como um processo noturno. O conteúdo seo estático pode não ser o mais atualizado durante o dia, mas não vejo isso como um grande negócio. Ele apenas será atualizado durante o processo noturno.

@robertschneiderman também abordamos o problema de memória. Estamos perto de 1500 páginas, mas uma quantidade insana de imagens (blog de design). Desativamos os mapas de origem e impedimos que o build baixasse os arquivos de imagem, mas tivemos que editar o comando build para aumentar a memória alocada para a instância do nó. por meio da bandeira --max_old_space_size .

Uma coisa que me preocupa sobre esse recurso é a construção de esquema. Se não tivermos todas as postagens disponíveis para gatsby construir um esquema, nossas consultas gerarão erros. Seria muito bom se houvesse uma maneira de passar esquemas para gatsby, ou pelo menos fornecer entidades fictícias durante a construção para demonstrar as diferentes formas que podem assumir.

Estou pensando em usar Gatsby para construir a interface do usuário para um site de conteúdo com mais de 5000 itens, a maioria com relacionamentos interconectados entre si. Os dados virão de um CMS baseado em banco de dados.

O benefício de usar Gatsby em vez de um site React padrão baseado em API é que eu gastaria uma fração do tempo construindo e mantendo a API de dados e o sistema de gerenciamento de estado que carrega os dados remotos e os armazena. (Como pretendo implantar este aplicativo em vários sites de tamanho semelhante, isso parece um benefício muito valioso.)

A desvantagem de usar Gatsby neste caso seria o fato de que todo o site precisaria ser reconstruído até mesmo para a atualização de conteúdo mais insignificante. Esqueceu de adicionar uma vírgula? Reconstrua todas as 5000 páginas! Quem sabe quanto tempo isso levaria? Isso é ainda mais problemático quando se considera a experiência dos usuários do CMS - eles estão acostumados a ver as alterações aparecerem no site imediatamente após salvá-las. Com Gatsby, esperamos alguns minutos (pelo menos) antes que a mudança apareça.

Se houvesse uma maneira de acionar compilações para um subconjunto de páginas, Gatsby seria a escolha certa e definitiva. Neste momento, porém, é difícil de vender.

BTW, tenho trabalhado muito para melhorar a velocidade de construções de sites maiores para a v2. No beta v2 mais recente - você pode construir 5.000 páginas em <1:30. Haverá mais melhorias de velocidade chegando.

Isso é incrível, @KyleAMathews! Eu definitivamente espero por isso! Avise-me se quiser testar um blog com muitas imagens

@KyleAMathews 5K é bom, mas precisamos de 1M 😉

Se quisermos compilar partes do site separadamente, podemos definir sinalizadores no build para que gatsby-node saiba apenas gerar as partes do site especificado. Poderíamos então adicionar de volta os arquivos estáticos gerados anteriormente . Isso funciona para nós, contanto que vinculemos os arquivos gerados anteriormente com <a href> básico ao invés de <Link to > .

Estou pensando se podemos fazer <Link to> funcionar ao vincular a arquivos gerados anteriormente se mesclarmos alguns dos data.json no momento da compilação. Olhando um pouco mais para isso no momento.

Não me preocupo com o tempo de construção, mas mais com o volume de arquivos estáticos que preciso fazer upload para qualquer atualização, lançamos um grande portfólio visual com Gatsby e o site estático para upload é superior a 150 MB
Principalmente imagens.
Isso torna o site indisponível cerca de 40 minutos durante uma atualização
A disponibilidade para reconstruir uma parte do site é definitivamente um recurso que impulsionaria Gatsby.
Pretendo usar Gatsby para um novo site, mas vou dividir o site em uma parte estática e dinâmica usando um CMS php tradicional para a parte de notícias.

@rbmedia você pode querer considerar um host que faz a comutação de implantação como o Netlify para que seu site atual continue funcionando até que sua nova versão esteja pronta.

Obrigado Matt, vou considerar!
Eu criei alguns sites de notícias com o Drupal no passado, qualquer atualização tinha que estar online em um curto espaço de tempo (menos de 2 minutos). Eu adoraria usar o Gatsby no futuro para esse tipo de site.

Alguma notícia sobre este assunto? Planejamos um site com cerca de 100 mil páginas e compilações incrementais seriam fantásticas.

faça outro caminho como pasta de página estática padrão, não '/ public'.
Após executar o gatsby build, copie ../public/* para o caminho padrão.

Hiya!

Este problema ficou quieto. Silêncio assustador. 👻

Temos muitos problemas, então atualmente fechamos os problemas após 30 dias de inatividade. Já se passaram pelo menos 20 dias desde a última atualização aqui.

Se perdemos esse problema ou se você deseja mantê-lo em aberto, responda aqui. Você também pode adicionar o rótulo "não obsoleto" para manter este problema aberto!

Obrigado por fazer parte da comunidade Gatsby! 💪💜

Ainda não acho que isso seja corrigido / suportado no Gatsby. Alguma notícia do @ TeamGatsby?

é um problema antigo porque é muito difícil de resolver sem pensar muito sobre isso. A @Moocar tem um problema em aberto para, pelo menos, nos dar um passo na direção certa.

O Gatsby atualmente rastreia quais nós GraphQL são recuperados em uma determinada página? Nesse caso, pareceria viável adicionar reconstruções incrementais com base nas alterações dos dados. Isso é metade do trabalho, não?

A outra parte do trabalho é fornecer plug-ins de origem com um cache e encorajar os desenvolvedores de plug-ins a buscar apenas os dados alterados quando possível. Em muitos casos, isso é trivial.

@coreyward Sim, Gatsby rastreia cada nó que é retornado para uma consulta (via page-dependency-resolver.js ). É o que capacita gatsby develop a capacidade de reexecutar consultas apenas para dados alterados. No momento, não salvamos essas informações em disco, portanto, ainda não são usadas para gatsby build mas esse é definitivamente o plano.

Sei que, para nossa equipe, esta será a decisão ir / não ir contra o uso de Gatsby para a reconstrução de 2019 de nosso site principal. Eu realmente espero que ele seja lançado ou pelo menos esteja no horizonte quando começarmos a construir. Apoiamos centenas de autores da web na edição de várias partes do site ao longo do dia de trabalho. Quando clicam em salvar, eles esperam que o conteúdo seja atualizado. Não é incomum que eles voltem apenas para corrigir uma vírgula ou alterar a data na postagem.

@mattbloomfield , temos mais clientes interessados ​​nisso, portanto, estamos no topo da lista de prioridades.

estamos implementando gatsby com um back-end drupal 8 usando o plugin gatsby-source-graphql, e o desempenho não é um problema até agora, com cerca de 4000 páginas criadas em menos de 30 segundos. estamos puxando todos os dados em gatsby-node em vez de rodar milhares de StaticQuerys, e ignorando o processamento de imagem por enquanto.

`` `
sucesso na execução de consultas Graphql - 3.088 s - 4008/4008 1311,56 consultas / segundo
sucesso de gravação de dados da página - 0,070 s
sucesso de gravação de dados de redirecionamento - 0,001 s
Sucesso Build manifest e ícones relacionados - 0,117 s
sucesso onPostBootstrap - 0,127 s

info bootstrap concluído - 15.751 s

sucesso Construindo pacotes de JavaScript e CSS de produção - 3.361 s
sucesso Criação de HTML estático para páginas - 6,906 s - 4006/4006 609,25 páginas / segundo
Informação Concluída a construção em 26.047 seg

Atualmente estou avaliando o uso de Gatsby para acelerar um antigo site Rails 3.x hospedado em Heroku que é lento como melaço. Tem cerca de 1 milhão de páginas, portanto, compilações incrementais são a única maneira de funcionar. A maioria das páginas não muda, então torná-las estáticas parece uma grande vitória, mas novas páginas são constantemente adicionadas e algumas páginas antigas são editadas. Os usuários esperam ver as mudanças em segundos. Minha esperança era adicionar código suficiente ao aplicativo Rails para torná-lo um servidor JSON API e gerar um novo front-end com Gatsby, com ativos estáticos hospedados em algum lugar como Netlify ou S3.

Eu estava pensando que seria capaz de fazer algo como executar uma compilação incremental de Gatsby por meio de um trabalhador de fila de trabalho. O servidor Rails API sabe quando uma página é atualizada, então ele criaria um 'trabalho de atualização da página' usando o page_id (uma chave no banco de dados postgres), e o trabalhador passaria isso para Gatsby com uma var ENV com algo como PAGE_ID=1235 gatsby build . Eu usaria essa var ENV em createPages () para pesquisar apenas o que é necessário para aquela página e construí-la. Os arquivos de saída resultantes seriam transferidos para o host estático (espero que haja um gancho de construção para isso). Se nenhum PAGE_ID var for definido, ele criará todas as páginas normalmente.

Se uma página for excluída, a API Rails criaria um trabalho que exclui os ativos diretamente do host estático ou talvez haja algo necessário de Gatsby, então eu ainda executaria isso com uma variável ENV diferente. (Estou pensando em precisar, no mínimo, do caminho da página).

Estou latindo para a árvore errada pensando que Gatsby é compatível com esse tipo de projeto? Obrigado por qualquer ajuda.

Temos uma versão alfa ativa. Ainda não são compilações incrementais, mas pelo menos o caminho a seguir.
você pode usá-lo instalando npm install --save gatsby@per-page-manifest

Mais informações:
https://github.com/gatsbyjs/gatsby/pull/13004

@mpoisot por enquanto por construção de página ainda não está funcionando. Não tenho certeza de qual é o prazo que você está considerando para este projeto. Se as consultas forem leves, gatsby pode ser uma boa opção para seu site, mesmo sem compilações incrementais.

cc @KyleAMathews @Moocar para dar uma explicação melhor sobre isso.

Ping isto, pois já se passaram alguns meses desde a última atualização e parece ser o lugar de ação. Vejo que o desmembramento do page-data.json ocorreu e eu o tenho usado.

Existe um conjunto mais concreto de requisitos e tarefas que impulsionam isso? Eu entendo que é um grande problema, mas sempre ajuda se for visivelmente dividido em problemas menores que podem mostrar progresso e tração.

@wardpeet @Moocar Não tenho certeza de quem é a pessoa / lista mais apropriada para pingar nisso, mas vejo vocês como os últimos ativos do projeto aqui. Alguma atualização quanto ao objetivo principal deste tíquete?

Ter uma boa conversa com https://twitter.com/dominicfallows/status/1169152367964643328?s=19

Ter uma boa conversa com https://twitter.com/dominicfallows/status/1169152367964643328?s=19

TLDR;

@KyleAMathews confirmou que Gatsby está trabalhando nos recursos de compilação incrementais hospedados pela Gastsby Cloud.

A versão "Gatsby Enterprise" auto-hospedada / no local, com compilações incrementais, é possível, mas eles ainda não estão trabalhando nisso ....

Dominic Fallows - Set 4 - A maioria dos fornecedores que escolhemos oferece uma opção autogerenciada / local, como o Gatsby OSS faz. Felizmente pagamos por eles, como faríamos com uma solução Gatsby Enterprise Cloud local de você.

Kyle Mathews - 4 de setembro - sim, com certeza - temos um caminho bastante claro para oferecer suporte a versões onprem do que estamos fazendo - é tudo Kubernetes, então deveria ser possível - mas onprem adiciona muita sobrecarga quando estamos inicialmente apenas trabalhando sobre o envio de algo que funciona 😅

Dominic Fallows - 4 de setembro - Ótimas notícias! Desculpe se eu perdi o que foi discutido em outro lugar, mas aquele roteiro inicial seria muito útil para empresas e desenvolvedores ter uma visão.

Kyle Mathews - 4 de setembro - É longe o suficiente agora que eu não poderia dar uma linha do tempo. Definitivamente, não este ano e também não gostaria de prometer no próximo ano. Depende de quão rápido podemos aumentar a receita e de nossa equipe de engenharia

É uma pena, pois bloqueia o uso do Gatsby como ferramenta para editores onde falamos de milhões de páginas canônicas e outras iguais ou de indexação.

Não faria sentido "ejetar" esse caso de uso como um projeto separado usando os mesmos conceitos / núcleo?

Recurso de fazer ou quebrar para 2020 decisões. Parece ser um bom lugar para investir todo o dinheiro VC 😀

Gatsby faz muitas coisas certas, mas longos tempos de construção o tornam absolutamente inutilizável em projetos maiores: / Discutimos a mudança do framework esta semana apenas por causa disso.
Faça uma construção mais rápida acontecer!

Concordo com o acima! Gatsby se torna uma solução de blog rápida e fácil ou implementa compilações incrementais / mais rápidas e fica pronto para a empresa.

Absolutamente correto; esbarrando nisso continuamente em projetos maiores. Sem compilações incrementais, Gatsby não é uma opção.

Construções incrementais em Gatsby Cloud corrigem esses problemas. Você pode se inscrever para o beta privado aqui https://www.gatsbyjs.com/builds-beta/

Nada sobre isso parece sugerir que ele suporte construções incrementais - apenas que tem os "tempos de construção mais rápidos para sites de Gatsby".

Eu ficaria preocupado com a implicação de que compilações incrementais estariam disponíveis apenas em um serviço Gatsby hospedado, em vez de disponíveis para serem usados ​​de forma independente.

Entendo o que você quer dizer, @dwightwatson, não há nada no site que diga que é "incremental". No Gatsby Days London eles demonstraram builds e eram definitivamente builds incrementais. Não tenho certeza de como isso é feito e se fará parte do pacote Gatsby ou se será apenas um serviço que eles fornecem.

Os investidores precisam recuperar seu dinheiro de alguma forma. 🙄

tentando construir um site muito grande com mais de 140.000 páginas

gatsby build é um tanto bom ... mas fazer a implantação é doloroso (zeit.co)

Não tenho certeza de como adicionar um rótulo a isso, mas estou colocando isso como um problema.

@gomflo existe uma maneira de construir seu site? Pode haver alguns frutos mais fáceis de resolver para melhorar os tempos de construção :) Sem promessas.

Nada sobre isso parece sugerir que ele suporte construções incrementais - apenas que tem os "tempos de construção mais rápidos para sites de Gatsby".

Eu ficaria preocupado com a implicação de que compilações incrementais estariam disponíveis apenas em um serviço Gatsby hospedado, em vez de disponíveis para serem usados ​​de forma independente.

Isto é ^: Se meu repositório gatsby estiver no gitlab e não no github, poderei usar os recursos de nuvem / compilação do gatsby?

Eu devo ter mencionado isso antes, mas em relação ao problema / recurso original. Para os editores, Gatsby fará sentido se pudermos acionar a única geração de novas páginas e talvez atualizar os índices. Quase nenhum editor se importaria em atualizar as páginas canônicas antigas.

Então, teremos uma atualização parcial autônoma ou nenhuma chance? Talvez haja outra maneira de atualizar apenas algumas páginas e não reconstruir todo o projeto?

Queria apenas atualizar que minha equipe está perto de publicar um PR no repositório Gatsby que acreditamos permitir compilações incrementais. Estamos apenas reservando um tempo para escrever um bom PR e aprimorar o código, mas vou atualizar aqui quando terminarmos (na próxima semana ou assim).

Queria apenas atualizar que minha equipe está perto de publicar um PR no repositório Gatsby que acreditamos permitir compilações incrementais. Estamos apenas reservando um tempo para escrever um bom PR e aprimorar o código, mas vou atualizar aqui quando terminarmos (na próxima semana ou assim).

Aqui está o PR https://github.com/gatsbyjs/gatsby/pull/20785

Atualização adicional do PR: https://github.com/gatsbyjs/gatsby/pull/20785#issuecomment -579355927

Novo PR, com foco em mudanças incrementais de dados https://github.com/gatsbyjs/gatsby/pull/21523

Com o # 21523 incorporado e as compilações incrementais disponíveis no Gatsby Cloud, acredito que esse problema foi resolvido. Ele não oferece suporte a todos os fluxos de trabalho, mas vou encerrar isso agora e pode ser melhor abrir um novo problema no futuro para empreendimentos futuros, se necessário.

Deve realmente ser fechado? A otimização era apenas isso - uma otimização. Não foram realmente compilações incrementais. Além disso, tudo o que está disponível por meio do Gatsby Cloud não está disponível por meio do uso do pacote público. Para o propósito específico deste tíquete, nada foi resolvido.

Deve realmente ser fechado?

Com base em https://github.com/gatsbyjs/gatsby/issues/5496#issuecomment -641005662, não acho que esse problema deva ficar fechado e não entendo por que o rótulo not stale foi removido .

Alguém aqui tentou, ou sabe se é possível, ajustar a configuração do webpack do GatsbyJS para produzir simultaneamente a visualização do desenvolvimento e a versão do build de produção com ”gatsby developers”? (Possivelmente resultando em "compilações incrementais" com custo de execução contínua do servidor de desenvolvimento.)