Se você tem se aventurado no mundo Jamstack/page rendering/Next.js, é provável que você já tenha ouvido os termos “Regeneração Estática Incremental” (ISR) e “ renderização persistente distribuída ”(DPR) flutuando. E se você não fez isso, você pode estar tipo,”Uau, essas são palavras longas que eu nunca vou entender.”É aí que você está errado! Você está prestes a entendê-los agora.
O que são essas coisas?
Esses termos são estratégias para construir sites de forma incremental . Normalmente, quando você implanta um site que não é renderizado do lado do servidor ou do lado do cliente, ele deve ser compilado e construído para o navegador carregá-lo nativamente (assim, por exemplo, seu JSX é transpilado para o vanilla JavaScript, seu SCSS compilado em CSS vanilla, seus modelos em HTML).
Conforme seus sites ficam grandes, você pode começar a ter que ter tempos de construção bastante longos, porque é muito para compilar. Geralmente, seus sites podem ter páginas em duas categorias:
Tipo A
Páginas “críticas” (página inicial, sobre nós, entre em contato) Tipo B
Páginas “adiadas” que podem não ser acessadas com tanta frequência quanto as páginas do Tipo A (catálogo de produtos, certas páginas de documentação)
Se você construísse este site de forma incremental, poderia teoricamente dividir sua construção onde As páginas do tipo A são criadas antecipadamente e, em seguida, as páginas do tipo B são criadas posteriormente!
Tanto o ISR quanto o DPR seguem essa abordagem, mas de maneiras um pouco diferentes.
Qual é a diferença entre ISR e DPR?
Para ambas as abordagens, as páginas Tipo A são construídas logo no momento da implantação. Com as páginas Tipo B, elas variam um pouco mais. A principal diferença entre essas duas abordagens é a imutabilidade. Quando digo imutabilidade, quero dizer que, uma vez que uma página é adicionada a uma construção, ela não muda, e cada usuário que acessar uma URL durante essa implantação sempre verá exatamente os mesmos dados.
Com ISR, suas páginas Tipo B são criadas em tempo de execução quando um usuário vai para a página. Cada uma dessas páginas tem um “tempo de expiração” (ou “tempo de revalidação”), onde será reconstruída com base no novo conteúdo que chega naquele momento (obtido em segundo plano). É baseado em uma estratégia de cache chamada”desatualizada durante a revalidação”, o que significa que uma página pode ser”desatualizada”com informações antigas até que seja regenerada e o cache seja atualizado. Essa abordagem não garante imutabilidade entre compilações. Quando digo isso, quero dizer que você não pode necessariamente voltar a uma implantação anterior com total confiança de que todo o conteúdo será como era no momento em que você executou originalmente essa página (isso é explicado em outra postagem do blog de Lee Robinson na equipe Next.js).
Existem prós e contras nisso; o principal pro significa que você pode ter seus dados que preenchem a página regularmente atualizados sem reconstruir o site, e o principal contra é que a depuração será muito difícil sem essa parte imutável (porque alguns usuários podem ver uma página desatualizada e outros podem ver o atualizado corretamente).
Com o DPR, suas páginas Tipo B também são criadas em tempo de execução, quando um usuário vai para a página. Quando as páginas não construídas são solicitadas pela primeira vez, elas são construídas e armazenadas em cache na borda para que não precisem ser construídas novamente. Uma vez que faz parte da construção, não mudará até uma reimplantação. Também há prós e contras nessa abordagem. A principal vantagem é que isso garante imutabilidade . Quando você acessa um URL, todos os usuários sempre verão as mesmas informações exatas. A desvantagem é que, se você quiser atualizar uma dessas páginas, precisará acionar uma reconstrução do site.
Como posso usar essas abordagens e comparar comigo mesmo?
Em um mundo ideal, essas abordagens são incorporadas às estruturas que você usa e não precisa fazer muito para usá-las. Agora, porém, você pode testá-lo com Next.js ! O ISR é integrado por padrão ao Next.js quando você o implanta em uma plataforma baseada em Node.js como o Vercel, e o DPR é integrado ao implantar no Netlify.
Você pode usar o DPR em outro frameworks também (Zach Leatherman tem algumas demos dele com Eleventy onde ele adia a construção de centenas de páginas), e A equipe do Next.js disse que ISR chegará a outros frameworks no futuro (como Nuxt e SvelteKit). Você também pode deixar um comentário sobre como o DPR é implementado (para qualquer plataforma Jamstack!) neste RFC .
