Como Programar Sites Difíceis de Cair? [Qualidade Profissional]

A gente vai programar dentro deste único vídeo tudo o que você precisa para colocar no ar e de graça páginas que são quase impossíveis de cair, que são absurdamente velozes e se revalidam sozinhas. . .

E essa parte é de explodir a cabeça. . .

E eu vou também comprar um domínio ". com. br" nosso ao longo do vídeo e mostrar como engatar isso no seu projeto e.

. . Eu tenho muito orgulho disso porque eu sei que depois que este vídeo terminar, literalmente vão ter pessoas tirando ideias na cabeça e colocando em código e vendo o seu projeto rodar em um domínio massa, nível produto de verdade mesmo!

Então, se prepara porque vai ser sensacional e você vai ficar fervendo com ideias do que fazer daqui para frente. E não interessa se você utiliza linguagens de programação como PHP, ASP. NET, Python, Ruby, Java, JavaScript.

. . Ou utiliza frameworks como Express, WordPress, Magento, Laravel, Django, Ruby on Rails, Sinatra, Spring ou o que seja!

O que eu vou mostrar aqui vai impactar como você encara todos esses frameworks web e plataformas atuais. Não com o intuito de substituir, mas de cobrar que essas soluções forneçam uma qualidade de serviço nesse patamar ou fazer você pensar como adaptá-las para chegar nesse nível de performance e disponibilidade, seja implementado do zero o que eu vou mostrar aqui, ou até melhor, unindo forças, porque dá e é muito fácil. Então, eu tenho certeza que o que eu preparei aqui vai te aproximar um pouco mais, um pouco bastante mais de ser um profissional em assuntos relacionados a desenvolvimento web no geral.

E sinceramente, eu não quero te ensinar só mais um framework e apesar que isso vai acontecer, o que eu realmente quero é que você se torne aqueles profissionais que conseguem abordar cenários difíceis e sabem lidar com eles, seja para acabar sendo mais valorizado pelo mercado, seja para se sentir mais seguro e confiante no dia a dia. E você vai entender exatamente o que eu quero dizer com tudo isso quando a gente chegar na parte em que, por exemplo, eu simulo um banco de dados sobrecarregado ou até fora do ar e ver que seu site não cai e não perde performance alguma. É muito massa e não tem mais como voltar para o modo antigo de fazer as coisas.

Na boa, não tem mais! Até porque você pode estar hoje servindo sites no modelo mais arriscado e demorado que existe que é utilizar páginas geradas dinamicamente a cada request que chega no seu servidor, no seu back-end, o que é extremamente comum, não é mesmo? É mesmo!

E este vídeo aqui faz parte de uma playlist que você não precisa assistir agora, eu já explico o porquê. . .

Mas eu vou fazer de tudo para você colocar o seu site ou sistema no ar da forma mais moderna possível. Onde a gente já passou pela história do desenvolvimento web e viu a diferença entre páginas estáticas, single-page applications e geradas dinamicamente. .

. E como que por a + b esse último modelo é o mais arriscado, demorado e como páginas estáticas recentemente começaram a contornar isso de uma forma surpreendente. Essa cobertura mostrou também empresas como o Nubank que estão usando a exata mesma abordagem e entenderam que extrema velocidade de resposta está se tornando o padrão, e como míseros 100 milissegundos podem reduzir em 7% as suas conversões ou as dos seus clientes.

Novamente, não precisa ver essa playlist agora, porque primeiro eu gostaria que você visse na prática como páginas estáticas hoje em dia e utilizando um framework chamado Next. js são tão dinâmicas quanto páginas geradas dinamicamente, principalmente com recursos de se autoatualizarem, se autorevalidarem sozinhas. .

. É brilhante! Então, este vídeo conta com quatro desafios ordenados por dificuldade e eu estou curioso para saber se você vai conseguir entender tudo do último desafio, porque esse é o "crème de la crème" de performance, disponibilidade e flexibilidade e é só para quem quer impressionar os usuários.

E do jeito que eu organizei os desafios, eles vão servir para pessoas do nível iniciante, intermediário e avançado. . .

Onde especialmente para o iniciante, eu quero ir injetando conhecimentos avançados ao longo do vídeo para ver como essa pessoa reage, como ela se sente e se ela não se sentir estranha, nesse ponto a didática deu super certo. Já para quem é intermediário, o vídeo fica ainda mais importante porque essas coisas você já deveria saber ou já deveria ter corrido atrás. .

. Então, ótima oportunidade para recuperar e economizar esse tempo, porque está tudo compactado neste único vídeo. E para quem é avançado, super bem-vindo a revisar e ajudar a levantar a barra nesse assunto.

Mas para começar, o mais justo é primeiro eu colocar todo mundo no mesmo barco. Super simples e eu vou revisar num piscar de olhos o que a gente fez no vídeo passado para todo mundo entender o que vai acontecer daqui para frente. Bom, a gente criou um repositório normal no GitHub chamado "ideia-unica", fez o clone na minha máquina local e daí a gente instalou as dependências relacionadas ao framework Next.

js. Em seguida, eu mostrei como programar uma página estática da forma mais simples possível para logo em seguida mostrar como fazer o deploy dela tanto em ambiente de homologação quanto em ambiente de produção e ficarem disponíveis através de uma URL acessível por qualquer pessoa no mundo. Isso tudo de graça, tanto a hospedagem do servidor feita pela Vercel, quanto a URL única que ela disponibiliza e que pode ser customizada para um endereço ".

com. br" e eu já vou mostrar aqui como fazer. Mas o mais importante é que tudo isso é servido usando boas práticas sem precisar fazer nenhuma configuração, como, por exemplo, ser replicado em 70 pontos pelo mundo, HTTPS automático, compressão de arquivos, invalidação automática de cache, code splitting e várias outras coisas que você ganha sem pensar de um ambiente feito por um profissional em infraestrutura e segurança.

Então agora, o que a gente tem em mãos é um repositório no GitHub chamado "ideia-unica" que tem o código do site. . .

E uma conta na Vercel hospedando e servindo esse site. Onde cada vez que eu faço um push para a branch principal lá no GitHub, automaticamente é feito um deploy dessa nova versão e tudo isso fica disponibilizado pela URL https://ideia-unica. vercel.

app. Mas essa URL apesar de única para o seu projeto, não é um endereço ". com.

br" bonitão, sabe? Então, o que acham de a gente marcar como concluído o primeiro desafio para completar o segundo que é aqui que o negócio começa a pegar. .

. Comprar e configurar um endereço ". com.

br" exclusivo seu. Essa parte é sensacional e muitas vezes um projeto "vai ou racha" por conta de um domínio massa, mas que infelizmente já tinha sido registrado por outra pessoa maluca. Por exemplo, nos vídeos desta série, eu estou batendo muito na tecla de hospedagem de site grátis e eu acho fantástico o fato de você conseguir testar a sua ideia de forma profissional sem pagar nada.

Então, vocês topam registrar de verdade um domínio ". com. br" justamente com isso?

Show! E o jeito mais oficial, vamos colocar assim, de registrar um domínio ". com.

br" é acessando um portal chamado registro. br e o endereço é esse também registro. br.

E agora chegou a parte mais crítica desse desafio que é achar um domínio disponível nos dias de hoje. Bom, eu vou tentar registrar aqui o hospedagemdesitegratis. com.

br que é 100% delicinha para o que eu quero, principalmente para SEO, ser encontrado nas buscas do Google, por exemplo. Então beleza, chegou a hora, vamos lá. .

. 3, 2, 1 e. .

. Aff, já pegaram! Aí nessas horas de raiva, digo de curioso, eu sempre acesso um endereço maravilhoso como esse para ver como estão usando de uma forma maravilhosa e.

. . Inês Remax Viva?

O que é isso, meu Deus do céu? Não tem nada a ver com hospedagem de site grátis. Bom, não foi dessa vez turma, mas vamos tentar um outro domínio.

Que tal "hospedarsitegratis. com. br"?

Vamos lá. . .

3, 2, 1 e. . .

Que delicinha! Será que eu digitei certo aqui? hospedarsitegratis.

. . Bom, é isso aí!

É, né? Sempre dá um nervoso registrar domínio com erros de digitação, mas ele ainda não está registrado por enquanto. .

. E eu vou registrar e pagar esse treco antes que você faça aí do seu lado! E como vocês podem ver a renovação é anual e eu vou no mais básico de todos, R$40 para um ano.

Clicando em registrar, ele te leva para uma tela pedindo o seu CPF e a partir agora eu vou borrar algumas informações pessoais, onde no seu caso pode ser questão de criar uma nova conta ou se logar com uma existente, como é o meu caso. Em seguida, ele te leva para uma tela chamada "Registrando Domínio" que vai listar novamente todos os dados pessoais do administrador da conta e a sessão mais especial é essa aqui "DNS (Opcional)". Se a gente abrir, tem um campo para dois servidores.

Para quem nunca mexeu com isso pode parecer estranho, mas no final das contas é bem simples. Então, antes de eu pagar o domínio pra valer, deixa eu rapidamente explicar o que essa parte significa para o seu projeto. A gente hospeda um site num servidor, correto?

Esse servidor tem que estar conectado à internet, logo ele tem IP exclusivo só para ele. A grosso modo e conhecendo esse IP, eu posso como usuário digitar isso no meu navegador, chegar diretamente no servidor e acessar o site que está lá normalmente. Inclusive, eu mostrei isso em uma live aqui do canal, aquela sobre a playlist do jogo multiplayer, onde eu convido a turma para jogar junto comigo um jogo que a gente programou e a única coisa que eu passei foi o IP.

E obrigado aos espertinhos que fizeram de DDoS e obliteraram o servidor no meio da live. Foi muito massa! De qualquer forma, você não vai querer passar para frente um endereço de IP, ninguém vai lembrar.

. . E é por isso que existem os domínios.

Um domínio é basicamente um apelido fácil de lembrar para o IP do seu servidor, tem os efeitos práticos de um redirecionador bem grosseiramente falando. E para guardar essa lista entre quais domínios levam para quais IPs, foi inventado um negócio chamado DNS (Domain Name System), que não passa de uma espécie de lista telefônica, só que ao invés de registrar a relação entre nome da pessoa e telefone, ele registra nome do site e IP. Então, naqueles campos da sessão DNS, a gente deve colocar o endereço real do nosso servidor, porque com essas informações o domínio e onde está de fato nosso servidor, o registro.

br vai fazer a propagação de DNS, a propagação dessas informações e atualizar "listas telefônicas" espalhadas pelo mundo inteiro. Essa propagação não é instantânea e ela vai acontecendo em fases que podem demorar minutos, horas ou até dias para que o cache de todas essas listas telefônicas espalhadas pelo mundo seja revalidado e eu vou mostrar um vídeo aqui desse negócio acontecendo e é muito massa. Mas vamos configurar isso depois, porque quem vai nos dar a informação do que preencher ali vai ser o servidor, que no nosso caso é a Vercel, e vou mostrar lá dentro onde encontrar e fizeram de um jeito simples e genial.

Então, continuando onde a gente parou no registro. br, vamos passar pelos termos e condições, confirmar que leu e registrar. Massa!

E nesse exato momento vai chegar na sua caixa de entrada um e-mail apenas confirmando que o pedido de registro entrou numa fila de processamento e um minutinho depois vai chegar este outro e-mail aqui. Nele, você vai encontrar um link que leva para o pagamento desse domínio e clicando nele, o registro. br oferece por padrão pagar por dois anos.

. . Eu vou trocar aqui para um ano apenas.

. . E depois de prosseguir, ele pede para confirmar e confirmando, a gente entra numa parte muito importante.

É aqui que você faz de fato o pagamento e pode escolher entre pagar com cartão ou boleto bancário. Vamos escolher cartão, porque se você pagar com boleto pode demorar até uns 2 dias úteis para confirmar o pagamento e liberar o domínio, onde com o cartão é praticamente na hora. Então, depois de preencher os meus dados e clicar em confirmar o pagamento, eu recebi no meu celular um aviso que o valor foi debitado do meu cartão e dentro dos mesmos minutinhos eu recebi alguns e-mails, sendo o mais importante um avisando que o pagamento foi quitado e esse e-mail demorou uns dois minutinhos para chegar, mas pode demorar mais.

E agora, abrindo a sessão painel, eu posso ver os domínios que eu tenho registrado. Dá para ver o BrasilAPI, o meu site pessoal e por fim o nosso endereço mais fresquinho de todos e com status de publicado. Show!

Deu certo. Agora falta a gente configurar o DNS, correto? E isso é muito simples, basta a gente entrar na nossa conta lá na Vercel e avisar a eles que: "Olha, eu tenho esse domínio agora, me dá as informações de onde os servidores de vocês ficam para eu poder cadastrar isso lá no registro.

br? " Show! Então, eu acessei minha conta na Vercel e lembra que eles deixam configurar domínios customizados até na conta Hobby que é gratuita, muito massa!

Bom, o próximo passo é adicionar um domínio dentro do projeto, porque você pode ter vários projetos separados, cada um com o seu domínio. E entrando nesse projeto, acessando o menu Settings e clicando no submenu Domains, ele mostra que esse projeto tem aquele domínio que a gente estava usando antes, mas que agora chegou a hora de adicionar o domínio que a gente acabou de comprar. Vou digitar o nome dele aqui e clicar em Adicionar.

E instantaneamente, ele fala que a configuração está inválida. . .

Excelente, porque está mesmo. E para continuar, ao invés de pegar o endereço IP do servidor, eu prefiro usar Nameservers, porque daí eu tenho um par de domínios redundantes e esses domínios se responsabilizarão por chegar no IP real da máquina. E não precisa configurar mais nada dentro da Vercel, o que a gente precisa agora é voltar para o registro.

br e colocar essas informações lá. Show! Vou copiar este primeiro endereço aqui, navegar até a sessão DNS e clicar em alterar servidores DNS.

. . E inserir o primeiro servidor nessa primeira linha e o segundo servidor nesta segunda linha.

E depois de clicar em Salvar Alterações, você pode receber duas mensagens: uma principal falando "DNS atualizado com sucesso" e outra com menos destaque em azul falando que os servidores DNS do domínio se encontram em transição, porque de fato a partir de agora vai começar a acontecer aquela propagação de DNS que eu comentei antes. Então, nota que nesse exato momento a Vercel está consultando o nosso domínio e verificado que o DNS que está lá é aquele temporário do próprio registro. br e isso é ótimo se ela reclamar disso, quer dizer que a gente está no caminho certo.

E enquanto o DNS propaga, você pode manualmente clicar botão de atualizar aqui ou deixar a própria Vercel ficar atualizando sozinho para você. A usabilidade é muito boa e inclusive você nem precisa ficar nessa tela, eles vão ficar tentando atualizar isso nos bastidores e te avisar por e-mail se está dando certo ou errado. E como eu falei, isso pode demorar horas e horas.

. . Então, para acompanhar o progresso dessa propagação, você pode usar um site chamado What's My DNS.

Basta digitar o seu endereço, selecionar a opção NS, de Name Servers, e ao buscar dá ver que de fato, por enquanto ainda está propagado pelo mundo aquele endereço temporário do registro br. No meu caso aqui demorou mais ou menos umas duas horas para começar a aparecer atualizado e eu fiquei filmando e dando refresh o tempo todo, e com a magia da edição, olha como que o novo endereço vai propagando pelo mundo, muito massinha, né? Deu um trabalhão, mas foi massa registrar isso acontecendo.

E na hora que a Vercel pegar essa atualização, ela vai dizer que o domínio foi configurado com sucesso e turma. . .

Está aqui o nosso site num endereço ". com. br" massa de verdade e acessível por qualquer pessoa nesse mundo.

Eu deixei esse endereço na descrição se você quiser testar e eu não sei exatamente o que vai aparecer na sua tela no momento que você tiver acessando e vendo este vídeo, porque eu vou mexer nos conteúdos dele, onde inclusive é o que a gente vai fazer agora. Então, isso significa que a gente completou o desafio e agora o próximo é navegar entre páginas instantaneamente. E nisso tem um detalhe, um capricho que vai deixar a navegação entre páginas em uma qualidade muito, mas muito profissional.

Mas antes, eu gostaria de rapidamente fazer um agradecimento público a todas as pessoas que se tornaram Membros da Turma pelo vídeo anterior. Eu perguntei se na avaliação delas, os conteúdos do canal valiam R$5 e várias pessoas responderam que sim. .

. Então, novamente, muito obrigado. Hoje, vocês são os principais responsáveis por trazer segurança para mim e para a minha família, continuar levantando a barra na hora de produzir conteúdos aqui no YouTube e que ficam disponíveis de graça para todo mundo e este é um ponto muito importante.

O objetivo deste programa não é criar conteúdos de tecnologia que vão ficar presos e escondidos dentro do espaço exclusivo para membros, é o contrário! O apoio dessas pessoas vai diretamente para todo mundo que não tem essa oportunidade e está procurando por uma através da aquisição de novos conhecimentos. Então, se na sua avaliação o conhecimento deste vídeo já ultrapassou o valor de R$5 e isso de forma alguma vai faltar no seu orçamento mensal, considera se tornar um Membro da Turma.

Pode até clicar agora no botão Seja Membro que você não vai sair deste vídeo, só vai aparecer na frente uma outra tela com um outro vídeo bem rapidinho explicando todos os detalhes, combinado? E se você acha que não valeu os R$5 ainda, não tem problema! Só me dá mais uma chance porque eu quero me esforçar dentro deste vídeo e chegou a hora de a gente voltar para o desafio de realmente navegar entre páginas instantaneamente.

Olha que louco que vai acontecer na sua frente a partir de agora! Estou aqui na branch principal do nosso repositório e dentro da pasta pages temos um único arquivo chamado index. js com a nossa Home e se eu rodar o meu projeto localmente e acessar, a temos aqui como esperado.

Lembra no vídeo passado que o Next. js trabalha com file-system routing, ou seja, cada arquivo dentro da pasta pages vai se transformar em uma página e uma rota real no nosso site automaticamente sem precisar de configuração. Ótimo, então eu vou alterar a nossa Home para agora ter um link apontando para uma nova página chamada Sobre, que ainda não existe.

. . E verificando aqui, apareceu certinho.

Próximo passo, eu vou copiar tudo esse código e criar um arquivo sobre. js que vai representar o caminho /sobre do nosso site, e como conteúdo, eu vou colar aqui e substituir tudo o que tem Home para Sobre e o link que leva para Sobre, agora vai levar para Home. Acessando o site, o link que leva para a página Sobre funcionou, tanto que olha aqui em cima, esse caminho, essa rota existe agora.

E eu também posso voltar para a Home, como esperado. E é aí que a gente esbarra num detalhe muito importante relacionado à performance entre navegação de páginas e serve só para quem quer começar a raspar os preciosos milissegundos dessa interação e que a gente viu que faz muita diferença. Olha que interessante.

. . Imagina que essa página Home é bem mais complexa, mais pesada, cheia de HTML para o navegador baixar e fazer o parse, a interpretação disso.

. . E navegar para a página Sobre também, imagine-a pesada onde agora o navegador talvez teve que desalocar da memória a página passada para remontar a nova página tudo do zero e isso acontece a cada navegação, tudo sempre começa do zero.

E para provar isso, eu vou abrir o dev tools para injetar no body da Home uma cor de fundo qualquer e essa cor só está na instância desta página agora, nesse exato momento, tanto que se eu navegar para a página Sobre, tudo começa de novo como esperado. E quando eu navegar de volta para a Home, a cor dourada de fundo some porque novamente, nessa forma tradicional de navegar entre páginas, tudo sempre tem que começar do zero, inclusive inicializar de novo todas as bibliotecas e frameworks front-end que você está usando. Mas a gente está aqui para desafiar o tradicional e ficar acima do que é considerado normal, não é mesmo?

Então, olha que coisa esperta que o Next. js consegue fazer lá no ambiente de produção e que programar isso do zero é algo super avançado, mas que foi abstraído de um jeito extremamente fácil. No código da Home, eu vou importar um componente React chamado Link de dentro do framework Next e usar esse componente para conectar as minhas páginas de um jeito especial.

Então, eu vou abraçar a tag "a" com esse componente e passar para ele o endereço que eu quero levar o usuário. Nota que a tag "a" ainda existe dentro do Link para você conseguir estilizar esse elemento como faz normalmente com o CSS. Ou seja, você não vai estilizar o componente Link, você continua normalmente estilizando a tag "a" para ter total retrocompatibilidade.

Show! Agora, eu vou fazer a mesma coisa para a página de Sobre e com isso feito, algumas coisas interessantes vão começar a acontecer por baixo dos panos. E para a gente ver isso, eu vou fazer o deploy dessas alterações lá para o nosso endereço de produção porque essas otimizações não acontecem aqui no ambiente de desenvolvimento, no ambiente local.

Para isso e como visto no vídeo passado, é só questão de eu fazer o commit das alterações e depois fazer o push para a branch principal, que nesse caso é a main. E voltando para a Vercel, ela automaticamente já vai fazer o built e deploy para a gente. Nota que aqui embaixo tem aquele outro deploy em ambiente de homologação que a gente fez no vídeo passado também e que ainda está pendurado, mas deixa aí por enquanto.

Bom, terminando o deploy, eu vou fazer o refresh da página. . .

E pimba! Está aqui. E é agora que algo muito bom para a performance vai acontecer.

Abrindo o dev tools novamente, mas agora acessando a aba de Network, nota muito bem o que vai acontecer. . .

Só pelo fato de eu passar o mouse por cima do link, eu não vou clicar, eu só estou passando o mouse. . .

Ele automaticamente já fez o "prefetch" dos conteúdos da página seguinte. Investigando essa requisição, dá para ver que os conteúdos da página seguinte em forma de componente React transpilado, ela está toda aqui carregada, interpretada e prontíssima para ser mostrada em tela quando precisar. E quando eu clico de fato no link, turma, a rapidez chega a ser obscena, não dá nem para piscar!

E o Next. js vai continuar sozinho administrando os pedaços de código que precisam carregar, para conseguir atingir a navegação mais rápida possível. E uma das estratégias é automaticamente transformar a página em uma single-page application.

Ou seja, se eu voltar a colocar no body aquela cor dourada, nota que agora o navegador não recarrega a página e começa tudo do zero. Isso é muito custoso! Não sei se dá para notar no vídeo, mas parece que eu estou navegando em localhost, parece que os arquivos estão na minha máquina local de tão rápido.

E olha, não está errado. Os arquivos já vão estar de fato na máquina local do usuário, porque a demora real de ele passar o mouse em cima de um link e decidir que está no link certo e clicar de fato, em grande parte das vezes vai dar tempo para carregar o conteúdo seguinte fazer o parse e colocar pronto na memória da aplicação, para ela simplesmente trocar a tela. Então, eu me arriscaria dizer que é até mais rápido do que já estar nos arquivos locais do usuário, porque nesse momento, os dados vão estar até na memória do navegador interpretados ali dentro do seu aplicativo web com tudo pronto para aquelas linhas de código serem acessadas instantaneamente.

E agora, só de fazer isso você conseguiu juntar os benefícios sobre responsividade de um single-page application para navegar entre páginas com os benefícios de disponibilidade e SEO de páginas estáticas, porque elas continuam vindo inicialmente de forma estática com o HTML cru. Por exemplo, se você acessar primeiro a página Sobre, vai vir o conteúdo estático dela perfeito para SEO e disponibilidade e quem vai ser carregado dinamicamente por baixo dos panos vai ser a Home. Lembra que no vídeo passado eu falei que a divisória entre os três modelos páginas estáticas, single-page applications e páginas dinâmicas começaram recentemente a se borrar?

Show! Se prepara porque vai borrar ainda mais, e a gente vai ver isso agora. Com o desafio três concluído com sucesso, a gente vai subir um pouco a barra de dificuldade e encarar o desafio cozinhar páginas estáticas, mas que se atualizam sozinhas.

Olha que frase louca: páginas estáticas que se atualizam sozinhas, que se revalidam sozinhas. . .

E eu digo que é louco porque isso é estático ou dinâmico? E a resposta é estático, porque você tem todos os benefícios e características de páginas estáticas, mas como a divisória entre os modelos começou a borrar, você começa a ganhar alguns benefícios dos conteúdos dinâmicos. Olha só que sensacional.

. . Eu vou usar aqui um conceito que você já está acostumado que é o tempo, principalmente o tempo passando a cada segundo.

E isso é ótimo, porque a natureza do tempo de previsivelmente se atualizar sozinho, a gente querendo ou não, faz ele ser um ótimo recurso para a gente entender até que ponto a gente consegue mostrar um conteúdo atualizado em uma página estática. Então, para ajudar a modelar isso na sua cabeça do jeito certo, eu vou criar uma nova página e rota chamada tempo e a gente vai começar a estressar essa página. No componente principal dela, que eu também vou chamar de tempo, eu vou instanciar uma data e dela eu vou extrair uma string pelo método toGMTString que vai ficar mais fácil de ler na tela.

Show! Basta agora eu retornar isso na parte visual do componente e eu vou colocar um detalhe que esse valor é dinâmico. E eu destaquei que é dinâmico, porque apesar de a gente ter colocado essa informação no front-end da página, primeiro ela vai ser renderizada no servidor para ter o máximo de SEO possível.

. . E depois que alguém acessar essa página de verdade e esse HTML ser interpretado pelo seu navegador, o Next.

js vai automaticamente pegar tudo isso e hidratar a página toda com código dinâmico, com código vivo e que vira uma aplicação React qualquer. Tanto que se eu acessar essa página/tempo aqui no meu navegador, nota que toda vez que eu dou um refresh, vem a data e o horário mais atualizado possível porque no final das contas, o código desse componente, o que cria e renderiza a data, foi rodado aqui no front-end também. Mas agora imagina que esse tempo na verdade é qualquer outra informação que você precisa que esteja atualizada na sua página, mas que possa ser algo pesado no seu back-end ou que possa se transformar em algo super pesado, caso você receba um pico de acesso.

Ou que fique pesado devido a alguma outra rotina nada relacionada ao acesso do usuário, como, por exemplo, um backup planejado ou não e que vai sugar toda a potência do seu banco de dados e até travar algumas consultas em alguns casos. Ou o back-end de um outro serviço de onde você puxa essa informação precisou passar por uma atualização crítica de segurança e o servidor dele está totalmente fora do ar enquanto reinicia. Tem infinitas possibilidades que podem fazer dados ficarem inacessíveis, devagar, mas ao mesmo tempo são dados que, por exemplo, estão na Home do seu site e você não quer por nada degradar a experiência de acesso do usuário.

Então, para aprender a contornar isso, vocês topam a gente manter aquela data dinâmica que já existe e embaixo criar uma nova data, mas que seja à prova de balas, à prova de instabilidades e que se revalida sozinha? Novamente, imagina que esse dado possa ser qualquer coisa e vir de qualquer lugar, um banco de dados, um endpoint de um outro serviço, de um WordPress, de uma plataforma de e-commerce, uma API feita em Java, PHP, C#, tanto faz! Fora que nessa parte, a gente já pode usar qualquer código back-end em JavaScript que a gente quiser para não precisar passar por nenhuma outra implementação.

Então, olha que massa. A gente aprendeu que uma página para o Next. js não passa de um componente React, correto?

Então, mandatoriamente, essa função é um componente React tradicional. A gente aprendeu que todo o componente recebe uma propriedade chamada props, que é por onde a gente injeta dados para dentro do componente. O quão massa seria se antes de o site ir para a produção, a gente pudesse pegar dados vindos de qualquer lugar, onde mesmo que se fosse uma rotina super demorada, no momento que os dados chegassem, o back-end conseguisse congelá-los, deixá-los estáticos e injetar isso aqui dentro desse props.

Meio que uma página conseguir pegar estaticamente os props, tem como e é muito fácil, basta usar uma função especial chamada getStaticProps(), pegar os props estáticos. . .

E nessa função, ela é chamada somente no processo de build da aplicação. Então, nessa linha do tempo você tem três modos, três estágios que uma aplicação pode passar. Modo desenvolvimento, que é o que a gente usa para programar para valer na nossa máquina e ele propositalmente não tem várias otimizações que vão para a produção, justamente para ser mais rápido de desenvolver.

Depois, o estágio de Build. E isso roda apenas uma vez. E em resumo, esse estágio vai construir todos os HTMLs que precisa construir, otimizar tudo o que precisa otimizar, remover todos os aparatos que facilitam o desenvolvimento e congelar tudo o que precisa congelar para deixar tudo dentro de um pacotinho, um artefato pronto para ser publicado em produção.

Por último, o estágio de produção que é esse artefato, esse pacotinho rodando de verdade, sendo alto escalado ou não, conforme a vinda dos acessos e fazendo novas consultas dinâmicas no back-end ou outras coisas relacionadas a um trabalho normal de um site normal. Então, o getStaticProps(), para gerar de forma estática as propriedades que vão entrar numa página, roda uma só vez no estádio de build antes de entrar em produção. Mas em desenvolvimento, em ambiente local, para a gente ver o resultado das nossas implementações com mais comodidade, o Next.

js roda o build automaticamente a cada refresh de página. E turma, vocês não sabem o quão próximo vocês estão de vivenciar o maior borramento de limite entre páginas estáticas e dinâmicas da história. Olha só que massa e a gente vai por passos.

Onde o nosso primeiro passo é receber dados estáticos por esse props e para isso vamos manter o export default do componente da página e adicionar um novo export especial chamado getStaticProps(). Feito isso, eu vou copiar a geração da data aqui de cima, mas renomeá-la para static, só pra ter um diferencial. .

. E novamente, esse código pode ser qualquer coisa, inclusive ter dados sensíveis do seu back-end que nada disso aqui vai para o front-end, eu vou mostrar mais para frente. Bom, com os dados que você quer em mãos, basta retornar dessa função um objeto com uma propriedade props, porque o props é o exato mesmo props lá de cima.

. . Olha que API delicinha de usar!

E por hora, a única coisa que eu vou retornar é a chave e valor do staticDateString, porque novamente, depois do build e criação desse valor, isso vai ser injetado aqui no props do componente da página. Então, na parte visual, eu vou colocar um divisor e duplicar essa linha, e na parte de baixo, basta eu usar normalmente aquele valor está vindo pelo props e que para esse caso, eu vou destacar que é algo estático. Agora, se eu salvar e acessar essa página em modo desenvolvimento, quando eu fizer o refresh, ambos os valores vão vir atualizados, porque novamente nesse modo a cada refresh que eu dou, por conveniência o Next.

js roda o build antes. Mas se eu voltar para o terminal, commitar todas essas alterações e fazer o push para inicializar um novo deploy, olha que interessante que vai acontecer. .

. No momento que eu acessar a página/tempo no ambiente de produção, lembra que esse valor aqui foi gerado em tempo real, aqui no front-end que está na minha máquina mesmo. .

. Agora esse daqui não, ele foi gerado lá na infra da Vercel, no momento do build lá e independente de quantas vezes eu atualizar a página, o valor não muda, ele está cozinhado, está estático. Fora que já passaram os principais riscos de um back-end e se nesse momento o banco de dados que gera esse valor cair, não tem problema!

Essa versão do dado que está em produção já foi congelada no tempo. E nota que o dado dinâmico, apesar que ele sempre está atualizado em tempo real, também vem de forma estática no back-end para preservar o SEO como eu falei, onde o Next. js logo em seguida pega o que veio nesse HTML e nutre-o com código vivo e dinâmico e você pode fazer virtualmente qualquer coisa com ele.

Tanto que se a gente acessar o código-fonte que veio do servidor, a gente pode ver os dois valores cozinhados aqui como esperado. Então, para mostrar algo que vai ajudar muito lá no painel da Vercel e mostrar como que dados do getStaticProps() ficam só no nosso back-end, eu vou adicionar um log aqui e depois um outro log lá no nosso código que vai de fato para o front-end. Show de bola!

Vou fazer aqui as rotinas normais de commit, push e depois que o deploy terminar, a gente pode ver o que aconteceu clicando aqui no View Build Logs ou até de um jeito mais massa clicando em Deployments. É massa porque ele mostra a lista de todos os deploys que aconteceram, inclusive esse que acabou de acontecer e que adiciona os logs. Mas mais massa que isso é que se eu tivesse feito alguma besteira com esse deploy, eu posso simplesmente pedir para promover para a produção o deploy passado ou qualquer deploy, na verdade.

E show! Está aqui em produção o commit que mostra os logs e para inspecionar esse deploy em específico, basta clicar no botão Inspect Deployment. Olha que massinha!

Está aqui, tudo o que a Vercel rodou, não fica com medo, tá? Tem todo o ruído dos logs aqui, mas também tem todas as informações importantes, como, por exemplo, ela avisando que vai rodar a rotina de build da Vercel e que para esse caso, ela simplesmente rodou next build. E como esperado, na hora de gerar as páginas estáticas, ela vai passar uma vez pela função getStaticProps() para cada página e também pelo código front-end para tentar gerar o máximo de HTML possível para o SEO como eu comentei.

E como resultado, se a gente acessar o console da página em produção, a cada refresh a gente vai receber um log de passando pelo front-end, mas nenhum log do passando por getStaticProps(), porque isso já aconteceu lá no estágio do build e somente lá. É importante você dominar esse estágio de build, primeiro porque como eu comentei, você pode colocar qualquer informação sensível lá e fazer consultas a qualquer outro tipo de gerenciador de conteúdo ou sistema, mas mais importante do que isso. .

. Um fato de existir um estágio de build faz você poder correr os piores riscos de um back-end, inclusive uma sobrecarga absurda que vai deixar tudo lerdo. Eu digo isso porque você vai fazer o build pagar por esse preço e por essa demora uma única vez e de forma antecipada sem repassar esse peso para o seu usuário.

Olha só a simulação que a gente vai fazer agora e que demonstra isso. Eu copiei da internet esse trecho de código que cria uma função assíncrona de delay. Não importa muito como ela funciona no momento porque o mais importante agora é a gente simular um delay bem ruim na hora do build.

Então, eu vou transformar o getStaticProps() em uma função assíncrona, porque agora eu posso puxar dados assíncronos e também usar aquela função de delay para adicionar um delay bisonho de cinco segundos e simular que houve uma bela demora para buscar os dados. Inclusive, eu vou destacar isso também na parte visual do componente da página para a gente ter um diferencial. E esse delay é tão real que se eu testar essa página pelo ambiente de desenvolvimento e que gera aquele build a cada refresh, dá para ver como a página demora para retornar, correto?

Cada refresh em desenvolvimento gera um novo build, que vai passar pelo getStaticProps() que está com aquela latência de cinco segundos. Guarda essa demora na cabeça, porque levando tudo isso para o ambiente de produção e pagando esse custo e demora uma única vez na hora do build e que inclusive eu posso verificar nos logs que passou de fato por essa parte demorada, olha o que acontece no refresh da nossa página de verdade. .

. É instantâneo! A nossa latência ainda está no código, assim como um banco de dados sobrecarregado nesse exato momento, mas o que foi para produção já foi e está sendo entregue instantaneamente e ainda sem contribuir para mais peso no banco de dados.

Olha que maravilha! Você está notando como que cada vez mais tem um descolamento entre o que está acontecendo nos bastidores e o que está acontecendo no palco e tudo o que está lá no palco precisa funcionar adequadamente custe o que custar? Show!

Então, falta um último item para a gente completar esse quarto desafio que é fazer essas páginas estáticas se revalidarem, se atualizarem sozinhas a cada segundo, por exemplo. Isso é mega importante porque do jeito que está, os dados estáticos somente vão se atualizar caso alguém invoque um novo build, quando alguém faça um push para branch main, por exemplo. Para alguns cenários tudo bem, mas para outros não e é agora que a linha entre páginas dinâmicas e estáticas se borram de verdade.

Olha que maluquice e que absurdamente fácil é fazer isso. Primeiro, eu vou tirar todos os artefatos de delay do nosso código para entender o quão rápido a gente consegue fazer essa revalidação de dados estáticos. Agora, toda vez que eu quero que uma página revalide automaticamente os seus dados estáticos no getStaticProps(), basta eu adicionar uma propriedade chamada "revalidate" e definir quantos segundos eu quero esperar para revalidar os dados dessa página.

E que para esse cenário, eu quero testar um segundo. Vamos ver o que acontece. .

. Show! E agora, eu vou levar tudo isso para o ambiente de produção, sem nenhuma novidade aqui.

. . E eu vou direto para a página começa a fazer o refresh dela que nem um maluco aguardando o build lá na Vercel terminar.

Presta atenção no segund valor, no valor que está estático. . .

Opa! Começou a atualizar e continua atualizando sozinho, sem a gente precisar fazer um novo build manualmente. Ela está sozinha rodando o getStaticProps() e revalidando os dados e transformando-os em estáticos.

Lembra que o dado aqui de cima é dinâmico, ele está no client-side, por isso ele sempre está com o valor em tempo real. . .

E o dado de baixo teve que passar por todo um processo de geração de dado estático, ele passou por toda a maluquice que possa estar dentro do getStaticProps() e mesmo assim meio que está conseguindo acompanhar as atualizações do dado dinâmico. Não está ficando muito para trás não. .

. Mas agora nota um comportamento importante. .

. No segundo 25, eu vou parar de atualizar a página. Guarda esse número 25.

Agora, eu vou esperar alguns segundos sem atualizar e quando eu atualizar, o dado estático ficou com 25 e o tempo real já está no 33. Guarda de novo o 33. Vamos esperar alguns segundos e quando eu atualizar, agora o estático ficou no 33 e o dinâmico de novo está lá na frente.

Isso acontece porque a propriedade revalidate é a quantidade mínima de segundos que eu não quero que esses dados estáticos sejam revalidados, a quantidade mínima que eu quero mantê-los assim do jeito que estão lá em produção até que chegue uma nova consulta nessa página depois de passar desse estágio. Então, no nosso caso, se passou de um segundo e alguém visitou a nossa página, a Vercel vai entregar instantaneamente a página atual para ela que está em cache e automaticamente vai iniciar a geração de uma nova página por baixo dos panos, para que a próxima pessoa que chegar receba essa página atualizada instantaneamente. Isso é ótimo porque meio que a Vercel consegue segurar uma infinidade de requisições entrando nessa página e só fazendo uma consulta para o seu back-end para revalidar os dados e substituir o cache antigo pelo novo.

E essa revalidação só acontece se ultrapassar o range de frescura dos dados que você definiu na propriedade revalidate. Então, não importa se você configurar a revalidação para dez minutos ou um segundo, uma vez ultrapassando esse range e recebendo novos acessos que a Vercel vai ser mexer para computar tudo de novo uma única vez até que o próximo range de segundos seja ultrapassado. No nosso caso, meio que eu tentei abusar com o revalidate de um segundo para ver o quão próximo de um relógio em tempo real a Vercel conseguia ficar, mas o mais importante disso é que esse dado, essa página não cai mais.

E eu falo isso porque caso o seu banco de dados que esteja fora do ar ou back-end do WordPress que você usa sumiu do mapa. . .

No momento que a Vercel rodar o revalidate e dentro do getStaticProps() é gerado algum erro de conexão ou qualquer que seja o erro, ela não vai derrubar a página que está sendo servida para os clientes, ela somente vai sobrepor o que está no ar, o que está em produção se ela com sucesso conseguir revalidar os dados. Se não conseguir, deixa lá o que está funcionando até que o back-end volte. E quando voltar, revalida e atualiza o que está em produção, tudo de forma transparente e automática, sem frustrar nenhum usuário.

Então, meus sinceros parabéns! Você conseguiu completar os quatro desafios. .

. Mas e se eu te falar que ainda tem mais? Tem coisas que sinceramente são de explodir a cabeça e vão levantar muito a sua barra geral em desenvolvimento web, como geração progressiva de páginas ou até aprender a forma mais fácil e escalável de programar uma API, mas antes eu peço novamente que você reavalie se tornar um Membro da Turma.

Esse papo que a gente bate toda sexta-feira está se tornando o meu dia favorito no canal, porque é o dia que a gente senta para conversar sobre tudo o que a gente não conversa aqui fora, incluindo quais vão ser os próximos passos, quais são os próximos vídeos e quais coisas positivas aconteceram na semana de cada um. É um espaço com uma fonte inesgotável de alegria e com uma turma que eu estou ficando cada vez mais apaixonado. Fora que agora a gente vai começar uma campanha em que eu quero destacar nesses vídeos de sexta os serviços, empresas ou iniciativas dos membros para mostrar para os outros membros.

É uma oportunidade para falar sobre alguma vaga aberta na empresa que você trabalha ou mostrar um serviço que você faz para pessoas sensacionais e que podem estar interessadas ou podem dar feedbacks honestos para se ajudar mesmo. Até porque vocês vão tem uma coisa em comum que é ser Membro da Turma. .

. E isso se ramifica em várias outras coisas em comum. E no final das contas, se este vídeo aqui atualizou o seu jeito de pensar sobre algo e acredita que isso valeu R$5, por favor considera se tornar um Membro da Turma.

Você vai ser muito bem-vindo ou bem-vinda e tem muito mais benefícios, fora esse vídeo de sexta que eu comentei. Então, novamente, se você clicar no botão Seja Membro ou no link que está na descrição, só para espiar do que se trata, a primeira coisa que vai acontecer é aparecer um vídeo explicando tudo em detalhes. E se você acha que ainda não valeu R$5, não tem problema de novo!

Eu gosto de desafios e eu não vou te desapontar porque como eu comentei, eu quero te ensinar mais coisas sobre desenvolvimento web e Next. js, mas que são coisas mais avançadas. Por natureza não vão ser para pessoas de qualquer nível, mas o meu esforço aqui vai ser amaciar tanto essa didática, mas tanto que eu vou fazer isso entrar na sua cabeça da forma mais lisa possível!

Vai ser massa e você vai sentir um poder extremo em criar coisas para a web e para sempre. Então, para ver esse próximo vídeo é só clicar aqui e não se esquece de dar uma chance e ver como é legal se reunir com uma galera massa no Membros. Fechado?

Valeu!