Este vídeo tem muito, mas muito conhecimento
importante e consolidado em único lugar que vai passar desde uma rápida revisão
da história de se fazer páginas na web, até colocar a mão na massa,
programar linha a linha e hospedar o seu site de graça
da forma mais moderna que existe e com o mínimo
de configuração necessária e de um jeito que pessoas de todos
os níveis vão conseguir acompanhar, só que talvez,
o mais importante neste vídeo é destacar que: existe hoje
um conhecimento em desenvolvimento web que está mentindo para você. É um conhecimento antigo que para mim foi
difícil de inverter e aceitar de início, mas depois do click,
eu olho para trás e penso: Hummm! E a primeira impressão que dá é que: “Putz, isso é só mais
uma invenção de um moleque hipster, porque não quer usar as formas consolidadas
de se fazer desenvolvimento web”. Mas dessa vez não. E o plot twist, a reviravolta, vai impactar todo mundo
que quer continuar relevante nessa área. Então, dentro deste vídeo, eu vou explicar
em detalhes o que está acontecendo e mostrar para você passo a passo,
desde a primeira linha de código, qual é a forma mais moderna que existe
de programar e hospedar sites gratuitamente com altíssima performance
e disponibilidade. Inclusive, vou ensinar os três
principais modelos que existem de páginas e que você vai poder usar para virtualmente
conseguir construir tudo o que quiser. E para a minha infelicidade,
isso não é um conteúdo patrocinado. É pura empolgação mesmo. Eu preciso ensinar essas coisas
para vocês do meu jeito, porque eu sei que você vai sair
deste vídeo com um site na internet, com um link seu funcionando
e que você vai enviar para quem você quiser e construir o que quiser
daqui para frente, desde projetos pessoais de teste,
até serviços comerciais reais. E já de largada, eu acho honesto
destacar uma coisa muito importante: eu vou mostrar a forma mais moderna, e não a melhor forma de como
programar um site e hospedar. Eu digo isso porque
a qualificação de melhor, depende da mistura
com os detalhes do seu contexto, coisa que não tenho informação alguma. Só você tem,
só você pode fazer essa qualificação. Mas isso de nenhuma forma retira a qualificação de moderno
do que vou mostrar aqui. E independente desse fator, o que eu vou
mostrar aqui mexeu tanto comigo, que eu espero nunca mais
precisar programar de outra forma. Sério! E se precisar,
sem problemas também… Mas vai ser porque eu estou
resolvendo um problema especializado. E para isso é preciso de ferramentas
especializadas ou condições especializadas. Não tem como escapar e super natural. Então, bora? Porque não existe época melhor
para escolher a profissão de programador, principalmente, full stack, que é uma pessoa que quer resolver e ter
o controle dos seus sites de fora a fora, tanto programando no
back-end quanto o front-end. E nada melhor do que a gente revisar
rapidamente a história do desenvolvimento web, para entender o porquê desse plot twist e como isso vai afetar o que você vai
programar dentro deste vídeo. Bem no começo da internet, a maioria avassaladora das páginas
não tinham conteúdos dinâmicos, eram apenas documentos,
eram páginas estáticas. Ou seja, a exata mesma página era entregue
para qualquer pessoa que acessasse. Era uma época onde tudo era muito amador
e a internet tinha muito o que evoluir. Mas depois disso, houve um boom com a
invenção das páginas geradas dinamicamente, popularizadas muito com a vinda do ASP
e principalmente do PHP, onde para cada requisição, o servidor poderia computar uma página
diferente para quem estava consumindo. Isso destravou incontáveis
funcionalidades sensacionais na web, porque pela primeira vez era possível
pessoas e empresas fornecerem serviços que usavam informações
customizadas para cada usuário, e mostrou de uma vez por todas
que a internet veio para ficar. Mas algo estava faltando. Algo que na época, os aplicativos desktop,
por exemplo os instalados no Windows, ainda eram muito melhores, que eram na
usabilidade e interatividade em tempo real. E isso porque nesse modelo
de páginas geradas dinamicamente, para cada interação,
você precisava enviar uma requisição e voltava uma nova página
por inteiro como resposta. Para muitos serviços,
isso é ótimo e é até hoje… Mas para aplicações
que precisavam ser mais dinâmicas, isso era inaceitável. E para contornar isso, foi inventado o modelo
de Single-Page Application ou SPA. Nessa abordagem, o usuário recebia
no seu navegador uma única página e a aplicação JavaScript que estava nessa
página controlava todas as interações. Inclusive, carregar dinamicamente
somente pedaços dos novos conteúdos conforme o usuário interagia
com essa aplicação. Aí, o número de aplicações web explodiu! E o primeiro caso de impacto global
usando essa tecnologia foi o Gmail, porque até isso
os provedores de e-mail antigos usavam a abordagem de páginas
geradas dinamicamente, onde para cada interação do usuário
para, por exemplo, abrir o e-mail, era preciso recarregar a página
e o sistema inteiro, uma experiência infernal numa conexão
discada e com o Internet Explorer 6. E esse modelo que foi feito para aplicações
dinâmicas foi esticado nos seus limites e substituindo a necessidade
de instalar vários aplicativos desktop, onde depois de uma longa história
de bibliotecas e frameworks front-end, a gente encontra soluções como:
React, Vue.js e Angler liderando hoje. E é nesse ponto que começa
uma confusão muito interessante e que está ligada com o plot twist. De uma forma infinita as pessoas
brigavam e brigam na internet sobre qual o melhor modelo: o de páginas dinâmicas ou SPA’s, ao ponto de deixar as páginas
estáticas completamente de lado. Elas foram meio que esquecidas
pela maioria dos programadores e por muito tempo! Então, se você pegasse uma pessoa
mais tradicional em tecnologia e pedisse para ela ordenar
esses modelos do melhor ao pior, meio que ficaria nessa ordem: Primeiro e melhor, com certeza são
as páginas geradas dinamicamente, porque a maioria das soluções
são construídas dessa forma, tem vários benefícios de SEO e para vários casos você não precisa
nem de um framework front-end, dá para resolver tudo
aqui no meu ASP.NET ou PHP. Depois, SPA’s porque têm vários tradeoffs e servem só para coisas específicas,
como dashboards… E é uma camada a mais,
é mais difícil e estraga o SEO. E por último, páginas estáticas,
porque não sei, acho estranho. Não vejo ninguém usando
isso de forma séria, é muito limitado. Tem que ter dados dinâmicos
de alguma forma, até para um simples blog para,
por exemplo, mostrar os últimos posts de forma sempre atualizada. E é aí que vem o plot twist
que entortou o meu cérebro: essa ordem está errada,
ela está ao contrário! A forma mais antiga de se fazer,
que são páginas estáticas, e que nesse último exemplo foi classificado como a pior solução
por sua limitação, por exemplo… Na verdade, está virando a forma mais
moderna e a melhor para inúmeros cenários. E isso vai impactar praticamente todas
as plataformas de conteúdo e e-commerces que querem continuar relevantes. Porque com isso vem
benefícios realmente importantes tanto para o usuário que acessa quanto
para a segurança de quem desenvolve. Olha que massa… Daqui para frente, o formato estático vai dominar
a entrega de conteúdos na internet. São páginas em que o custo de processamento
já foi feito de forma antecipada. Então, não tem mais riscos ou problemas diretos
do banco de dados estar fora do ar, ou o back-end estar engargalado
e como consequência o acesso a essa página ser comprometido. Novamente, todas essas variáveis,
todos esses riscos e todos esses custos
já foram pagos antecipadamente e o resultado foi congelado,
vamos colocar assim. E talvez, essa é a parte que mais confunde a substituição de páginas
geradas dinamicamente por páginas estáticas… Mas a gente vai chegar lá. Bom, com isso sobra agora
distribuir esse conteúdo estático. E que pelo fato de o custo de processar
ser pago uma única vez para gerá-lo, distribuir acaba ficando
algo extremamente barato e você pode colocar múltiplas
cópias em múltiplas CDNs, levando facilmente a sua disponibilidade
para muito próximo de 100%. Vai estar tudo cacheado e, possivelmente, num ponto no
planeta Terra que está ao lado do usuário que está consumindo esse recurso, o que vai diminuir a latência
para a menor possível. E ainda, muito importante: páginas estáticas são dificílimas
de serem hackeadas, porque elas são entregues pelas CDNs como imagens estáticas
são entregues, por exemplo. Eu, ao menos, nunca ouvi de um caso
em que um servidor foi hackeado através da entrega
de um conteúdo no formato estático, como uma imagem ou um CSS. E um dos motivos é que esse tipo de material
estático não aceita inputs no back-end e nem está aberto
à SQL Injection, por exemplo. Então, a única forma de comprometer
esse documento por completo é conseguir hackear todas as CDNs e elas por si só também
são super fechadas ao input de dados. Só que é difícil aceitar que grande parte do que pelo menos eu acreditava
que precisava ser dinâmico pode e deve ser cozinhado
de forma estática. Isso, na verdade,
sempre foi possível fazer, não é uma novidade. Principalmente, dado ao fato que eu cabei
de explicar que é a internet começou assim, mas sempre foi um saco fazer, sempre era algo além,
vamos colocar assim. Seja esse “além” um plugin
adicional meio que não sei… Ou uma configuração
complexa em um proxy, numa outra camada que
você precisava dar manutenção específica. Mas agora esse jogo mudou e tem vários
frameworks que inverteram essa relação e fazem isso de forma nativa… E que estão sendo usados
por gigantes da tecnologia. A gente vai ver quem são
e eu me surpreendi, tem caso de um brasileiro grande, inclusive. Então, o segredo é que se vocês
estão usando o framework certo ou as abstrações certas, você pode a qualquer momento
atualizar essas informações estáticas, mas agora de uma fácil. Correto? Voltando ao exemplo de listar
os últimos posts de um blog ou as últimas notícias
de um portal de notícias tipo globo.com, não vai ter problema algum essa página
estática ficar desatualizada por 1 segundo. Ficar desatualizada somente
enquanto dá tempo de computar e renderizar uma única vez
a versão nova com as novas notícias e seguida ser distribuída
de forma estática para as CDNs. Versus toda a requisição
tem que passar pelo seu back-end, conectar no banco de dados
e computar tudo de novo. E muitas vezes, a exata mesma informação,
as exatas últimas notícias, porque nesse meio tempo
não teve nenhuma notícia nova. E nem que seja para pegar
as notícias de um cache, porque isso continua tendo
que passar pelo seu back-end. O ideal é tocar no seu
back-end o mínimo possível, porque essa é a parte
mais arriscada da cadeia inteira. Correto? Um jeito de encarar o quão pesado é isso, de uma página gerada
dinamicamente pelo seu back-end… Seria a mesma de, por exemplo, para
toda request de uma imagem no seu site, você no seu servidor
se conecta no Photoshop, mescla todas as camadas,
exporta isso num JPG e devolve para o usuário. É muito melhor a imagem
já estar pronta, cozinhada e replicada em vários pontos do planeta. E grande parte do seu conteúdo deveria
ser encarado dessa exata mesma forma. E eu vou mostrar como é simples fazer e como que hoje,
o estático não é mais estático. Mas se você não puder
usar esse formato, aí sim você faz o fallback para SPA, só que com um detalhe importante: você ainda deve usar
o modelo de páginas estáticas para entregar a aplicação front-end e apenas acrescentar o dinamismo
necessário tocando no seu back-end. Mesmo para uma área fechada como
uma dashboard ou um painel de controle, a aplicação em si, o front-end, vai se beneficiar muito ao ser entregue
de uma forma irrestrita por uma CDN, da forma mais veloz possível, para daí, após isso ser
hidratado com dados dinâmicos, que são sensíveis e que necessitam
de autenticação e autorização. E por último, tentando ao máximo
evitar esse modelo, você deve usar páginas geradas dinamicamente
pelo seu back-end a cada acesso. Esse é o modelo mais caro de todos, tanto para o servidor
quanto para quem está consumindo, porque o primeiro byte a ser transferido sempre vai precisar ser
computado por um back-end, que provavelmente não
vai estar distribuído globalmente e que vai gerar uma latência inicial, que principalmente
o modelo estático não tem. E esse é o ponto de performance
que muitas pessoas desconhecem. A mente humana percebe
o tempo de forma diferente conforme cada condição
que ela se encontra e isso não é mais novidade para ninguém. Um minuto a mais esperando
para chegar no trabalho… Não tem tanta diferença assim. Agora, o exato mesmo minuto
esperando para usar o banheiro, quando você está quase
fazendo um deploy demora muito mais. Você chega a ter a sensibilidade
de contar os segundos individualmente. Na web, isso é ainda mais sensível, tanto que especialistas em usabilidade
separam performance real do que é performance percebida, e a chave da sensação de performance
está na performance percebida. Entre acessar uma página gerada
dinamicamente em branco até chegar e carregar
os dados por completo… Ou acessar uma página estática onde
instantaneamente aparece um placeholder, mostrando que a informação
está carregando e depois a informação
chega de verdade… Na percepção das pessoas, a segunda opção vai parecer
mais veloz, mais performática, porque já de largada retornou
algo para elas instantaneamente. Muitos sites usam essa estratégia e talvez eu diria que o Facebook foi
o primeiro que abordou isso da melhor forma ou da forma mais popular, pelo menos. E mais performático do que isso, só entregar o conteúdo final
numa página estática. E até dentro disso tem uma estratégia
chamada Stale While Revalidate, que na verdade é o nome
de um response header do HTTP e que a gente vai ver
como é fácil de implementar. A estratégia é carregar instantaneamente
os dados que estão em cache, em alguns casos até
o cache do navegador do usuário… Mostrar mesmo um dado que
pode ou não estar desatualizado, mas que em paralelo,
de forma assíncrona, esses dados estão sendo revalidados. É uma estratégia que
não dá para fazer com todos os dados, por exemplo,
o saldo do banco da pessoa. Mas dá para fazer com muitos dados e isso vai dar uma
outra sensação na sua aplicação web. As pessoas vão querer acessar mais
o seu site, comprar mais pelo seu site, só pelo fato de ele responder
instantaneamente. Se você fizer pesquisa
sobre isso no reino do e-commerce, você vai ficar assustado. Tem estudos da Amazon falando
como somente 100ms demora a mais faz cair 1% das vendas deles. O Google mostrou um estudo
com uma projeção de bounce de pessoas desistindo do seu site
e de comprar nele, conforme a demora de carregamento. Ou mais absurdo ainda, uma pesquisa da Akamai mostrando
como milissegundos são críticos, onde, novamente, somente 100ms
podem afetar conversões em 7%. Ou 53% de usuários acessando
o seu site pelo celular vão sair se a página demorar
mais de 3 segundos para aparecer! Agora você entende o porquê isso não
é um assunto de um moleque hipster, como um negócio que
você participa está sendo penalizado hoje por não mostrar
o mais rápido que puder algo na tela e como que isso vai te impactar, independente da plataforma preferida
que você gosta de usar? Eu não quero mais o meu usuário
esperando uma página em branco enquanto o back-end
está resolvendo devolver dados. Então, se você também não quer mais, a notícia boa é que tem muita coisa legal
envolvendo desenvolvimento web hoje em dia. E como eu falei, dentro deste vídeo, a gente vai
colocar a mão na massa no framework mais popular
e moderno nesse assunto e que consegue entregar as três formas de
desenvolver para web que eu comentei antes, só que de um jeito inédito! Eu quero mostrar todos os detalhes, tanto no front-end quanto no back-end, para você cobrir praticamente quase
todos os casos do jeito mais performático e com a maior disponibilidade
possível e turma… Está fácil, porque a gente
vai usar o Next.js. O Next.js é um framework híbrido em que você consegue refinar
o modelo de entrega de página a página e que na minha visão foi o primeiro
a consolidar em uma única solução a melhor experiência de desenvolvimento e os requisitos mais profissionais
de um ambiente de produção e eu já vou mostrar o que significa. Esse framework é open-source
e foi criado pela Vercel, empresa de hospedagem na nuvem,
que é liderada pelo Guillermo Rauch, o mesmo criador de bibliotecas
extremamente famosas, como o Socket.io e Mongoose. O interessante é que
tanto o Google quanto o Facebook contribuem diretamente para
o desenvolvimento do framework e hoje empresas como: o Netflix,
GitHub, Starbucks, Docker, Twitch, Uber, Airbnb, Apple, TikTok,
Trip advisor e Nike usam-no das formas
mais criativas possíveis. Turma, até a Nubank
está usando o Next.js na home deles. Tem alguma coisa acontecendo aí. Bom, a sensação que eu
pessoalmente tenho é que nunca foi tão fácil criar
um código livre de quase qualquer amarra e colocar no ar para receber acesso real. Receber porrada e aguentar! Um dos projetos que eu tenho
com a comunidade open-source e que vou falar um pouco mais
para frente num outro vídeo sobre uma novidade massa sobre ele, usa o Next.js com o Vercel e recebeu 132.000 requests
na sua API dentro de uma única hora, onde essa mesma carga
estava continuamente se repetindo por várias e várias horas e dias. Eu não vou falar o nome
da empresa que fez isso, mas foi uma das maiores
empresas de telefonia do Brasil e se você que está assistindo
este vídeo foi o responsável, um abração e foi mal banir o seu IP, mas… Turma, o mais massa é que foi suave. Eu fiquei sabendo porque a Vercel
me mandou um e-mail perguntando… Agora, um outro projeto mais light e que realmente
me mostrou, com o Next.js, como é mais fácil e veloz
você conseguir tirar uma ideia da cabeça e colocar no ar para as pessoas
usarem de verdade, foi uma newsletter que estou
fazendo com meu irmão, o Guga. Para você entender a velocidade
que tem um conteúdo estático sendo entregue por uma CDN, eu coloquei na descrição um link
para essa newsletter e clica só para ver a velocidade
que abre esse treco, a gente não precisa
nem se cadastrar, de verdade… Só clica para perceber o quão rápido
aparece o primeiro conteúdo na sua tela. É obsceno! E todo esse projeto,
tirando o serviço de disparo de e-mails, eu usei o combo Next.js + Vercel… E o mais massa é que é tudo de graça
para uma conta hobby. Eu acho isso impressionante,
porque no plano inicial gratuito deles é a Vercel quem está pagando
os custos de hospedagem para você ver se
o seu projeto vai dar certo! Ou nem precisa ser um projeto
que precisa dar certo. Pode ser um projeto pessoal, um rabisco,
uma ideia, um portfólio, um sisteminha… Qualquer coisa! Então, bora que a gente vai
ver muito código a partir de agora e eu quero dar um “balãozão”
e mostrar tudo o que for possível… Mas primeiro, eu quero mostrar
como configurar de fora a fora um ambiente de desenvolvimento
e depois de deploy, tanto para ambientes de testes e produção, que vai agilizar muito
a entrega de novas features. Será que é difícil? Bom, vamos ver! E a primeira coisa que eu vou fazer
é criar um repositório no GitHub para eu te mostrar o que é essa
experiência mágica de desenvolvimento web usando o Next.js e Vercel. São coisas que eu nunca tinha visto
implementadas de uma forma tão simples, tão fácil e tão transparente e que aceleram muito o desenvolvimento
e publicação de novas features. Inclusive, eu sugiro primeiro
que você veja o vídeo até o final para preparar o terreno na sua cabeça sobre
o que vai acontecer daqui para frente… E depois voltar e acompanhar lado
a lado os passos que eu fizer aqui. Fechado? E eu digo isso porque
o que vou mostrar aqui não é uma solução pronta como
um WordPress ou um gerador de sites. É uma camada abaixo de abstração. A sensação que dá é bare metal,
você está na base do negócio, mas que vai te deixar livre para construir qualquer tipo de solução web
daqui para frente. Show! Então, com o repositório criado, o próximo passo natural é pegar
o link dele e clonar na minha máquina. Em seguida, eu vou entrar na pasta
e abri-la no VS Code e aproveitar para expandir
o terminal integrado. E a partir de agora, você precisa ter instalado
na sua máquina o Node.js, no mínimo na versão 10.3, que é a menor versão
compatível com o Next.js 10. Massa! Então, como isso
é um projeto usando o Node.js, eu vou primeiro criar
um arquivo package.json, usando o comando “npm init – y” e esse “-y” é para o npm criar o arquivo
aceitando todas essas opções padrão. Agora com o arquivo criado,
eu vou instalar a dependência do Next.js pelo comando “npm install next”… E como ele é um framework pequeno,
isso deve ser rápido, e depois de instalar, deve refletir
como esperado no package.json, mas tem mais duas dependências
que a gente precisa instalar. O Next.js tem como dependência o React, tanto que se você aprendeu
o mínimo dessa biblioteca, você vai saber lidar
tranquilamente com o Next.js, e isso é muito massa! E como o React vai ser usado
para renderizar componentes para web, para o DOM do navegador, a ultima dependência
a ser instalada é o React DOM. Todas essas instalações poderiam
ter sido feitas com um só comando: “npm install next react react-dom”. Chegou então a hora de a gente
rodar o framework localmente e criar a nossa primeira
página estática e turma… Vocês não sabem o quão próximo
a gente está de colocá-la em produção. Mas não é uma produção gambiarra,
é uma produção nível profissional. Olha só… Como a gente instalou a dependência next, nós vamos rapidamente criar um atalho, uma nova linha de script chamada dev e que simplesmente
vai rodar o comando “next dev”. Agora, toda vez que a gente quiser
subir o servidor do Next.js localmente para desenvolver, basta rodarmos o comando
“npm run” e o nome do script, que no nosso caso é dev. Só que ao rodar, dá erro! Que massa! O Next.js está configurado com sucesso, só que ele reclama que não existe
nenhuma pasta chamada pages e que é para criar uma na raiz do projeto. E nesse ponto que vem
algo muito legal do Next.js: você não precisa configurar
as rotas do seu projeto, porque para cada arquivo
dentro da pasta pages vira automaticamente
uma rota e uma página, como era antigamente no PHP. Lembra? Então, como instruído, eu vou primeiro criar uma pasta pages
e dentro dela vou criar um arquivo index.js, que também pode ser “.ts”, caso você
queira programar com o TypeScript, e isso já vem integrado por padrão,
mas que por convenção o arquivo index é o que vai ser carregado quando
alguém acessar a home do seu site, a primeira página ou a página padrão que é para ser carregada
dentro de subpastas. Dentro desse arquivo, eu vou
programar um componente React, que representa nossa home. Não vai ter nenhuma funcionalidade e por enquanto vai
retornar uma simples tag div, só que imagina que ele está retornando
o seu site todo completão e bonitão. Mas entenda que dentro
de um arquivo JavaScript, eu posso ter vários componentes React, várias funções tradicionais… Como que o Next.js vai saber qual
componente/função representa a nossa página? Simples, basta usar o novo padrão
de módulos do JavaScript e exportar por padrão o componente que
você quer que seja renderizado como página. Feito isso, basta salvar, rodar aquele mesmo comando
para desenvolver localmente… E agora tem um servidor web
pronto para ser acessado na porta 3000. E abrindo no navegador aqui do lado, a gente tem a nossa página estática
como esperado, eu vou dar um zoom aqui… E o massa é que já vem
embutido auto reload, então qualquer coisa que eu mudar, vai ser refletido automaticamente
no navegador. Inclusive, eu vou usar o useState para rapidamente implementar
um componente com memória, com estado, e que nesse caso vai ser
o exemplo do contador que a gente implementou no vídeo anterior
a este, que foi exclusivo sobre React. Mas… O mais importante é notar que o Next.js
usa o mais novo Fast Refresh do React e isso significa que independentemente
das alterações que fizer, ele vai, ao máximo que conseguir,
manter o estado dos componentes, a memória, que nesse caso
é o valor que já foi somado no contador. Isso é perfeito porque
você consegue fazer ajustes no código, até na lógica do código, sem precisar manualmente colocar
o componente naquela mesma situação de novo para ver como ia ficar. Bom, agora que a gente
já tem uma página estática, vocês topam colocá-la no ar? Em produção? Num endereço de verdade na internet,
que vocês vão conseguir acessar aí? Massa! Então, bora! E a primeira coisa que vou fazer
é parar o servidor de desenvolvimento, pegar todas essas alterações
e comitar na branch principal. Na branch que representa produção mesmo,
e que nesse caso é a main. E em seguida, eu vou empurrar
isso lá para o GitHub. Eu estou dando uma atenção especial
sobre comitar na branch principal, a que reflete produção… Porque fazer o commit e push em outras
branches tem outros efeitos sensacionais, que eu já vou mostrar. É a coisa mais massa que existe. Então, agora que a gente empurrou
esse novo código para o GitHub, eu vou fazer refresh… E apareceu aqui tudo como esperado,
inclusive a nossa primeira página. O próximo passo
é entrar no site vercel.com e clicar em “Sign up” para se registrar… E novamente, para projetos pessoais
ou de pequeno porte, hospedar na Vercel é de graça. Só cuidado com o fair use, não abusa e nem descumpra
os termos de serviço, como em qualquer serviço do mundo. Bom, o próximo passo,
eu vou logar com a minha conta no GitHub, mas ele me dá um aviso adicional
informando que já tenho uma conta lá. Normal, para o meu caso aqui,
eu vou logar mesmo assim… E no seu caso vai ser mais simples. E na primeira tela que aparecer, a gente pode importar o repositório
para dentro da Vercel e é isso o que vou fazer. Basta copiar a URL inteira dele,
colar e continuar. Nesse ponto, apareceu
uma mensagem que não tinha antes, mas eu vou confirmar que sim,
que essa é minha conta pessoal. Em seguida, como eu já tenho
outras contas na Vercel, no caso, uma conta separada
para o time do Brazil API, eu vou selecionar que esse projeto
seja colocado na minha conta pessoal, na minha conta hobby. Em seguida, a Vercel te leva para o GitHub para pedir autorização
para ler e escrever em seus repositórios e que por padrão vem
habilitado para todos os repositórios. Eu não gosto disso, então eu só
vou habilitar de volta para o Brasil API, porque eu tinha removido
por completo essa integração para poder mostrar esse passo para vocês… E agora, eu faço um novo repositório e fica ao seu critério o quanto você quer
ser permissivo nesse ponto ou não. Massa! No último passo e você não vai
mais precisar fazer isso daqui para frente, a gente volta automaticamente para a Vercel e ela identifica que
o projeto está usando Next.js. E ela faz isso porque você pode
hospedar qualquer framework nela. E também pode hospedar o Next.js
em qualquer outro servidor. E clicando no botão de deploy, você pode acompanhar os logs
mostrando a instalação das dependências, o build dos estáticos ou a configuração das rotas
da sua API do back-end, caso tenha… E o que a gente vai ver
mais pra frente como fazer… E é nisso que o Next.js sai na frente
dos outros frameworks, na minha opinião. Só que nota um detalhe, o contador ali embaixo avisando
o tempo que já passou e turma… Fazer o deploy em produção
demorou 30 segundos, e ele já te levou
para a página de comemoração. Agora é correr para o abraço e está
aqui a nossa aplicação rodando na internet com um endereço de verdade,
acessível por qualquer pessoa e que pode ser customizado normalmente
para um endereço .com.br, por exemplo. Inclusive, na conta hobby,
não precisa pagar nada a mais, a não ser o custo do endereço, obviamente. Mas o mais importante
é que essa página estática está replicada em 70 pontos pelo mundo, com HTTPS de graça,
compressão de arquivos, invalidação automática de cache,
code splitting e muitas outras boas práticas
de um ambiente de produção feito por um profissional. Só que ainda o mais massa é que daqui para frente qualquer
deploy fica extremamente fácil, porque se você quiser
ir no modo maluco é só empurrar novas alterações
direto para a branch principal que toda essa maquininha
vai rodar automaticamente. Olha só… Eu vou remover toda essa bagunça
do nosso código aqui, deixá-lo mais limpo, comitar e empurrar para o GitHub… E uma coisa importante
já está acontecendo. Nesse exato momento, a Vercel
já iniciou o deploy de uma nova versão, mas eu dando refresh aqui, consigo acessar
a versão atual sem downtime algum, sem interrupção de serviço, onde enquanto isso, ela está fazendo
o deploy desse novo código que entrou, sem a gente tocar em nada. E no momento que termina, eu volto para o nosso site, dou refresh e está lá a versão
mas nova ao vivo para todo mundo ver. Mas sério! A maravilha vem agora… Se você empurrar uma alteração
de código para uma outra branch, a Vercel vai manter o site rodando,
a que está na branch principal, normal… E automaticamente
vai criar uma versão paralela a dele, uma cópia com o código
que está nessa branch e disponibilizar isso
para você numa URL única. Isso é sensacional se você
quiser testar implementações e mandar esse links para outras pessoas. Eu fiz isso direto com o Guga, meu irmão, quando a gente estava testando
as várias homes para a newsletter ou várias páginas pedindo
para a pessoa confirmar o e-mail, que são diferentes
para cada tipo de e-mail. A gente ficava comparando
inúmeras versões, tanto lapidando coisas
no layout quanto nos textos… Até chegar nessa última versão e turma,
sinceramente, a gente criou muitas versões e foi muito fácil compartilhar
tudo isso com ele lá em Blumenau. E não tem trabalho adicional algum, a não ser enviar um código diferente
para uma branch diferente e abrir um pull request. Olha que louco! Eu vou criar uma
nova branch chamada “testing”, porque eu quero testar
um novo título para a nossa home. Eu quero testar “Página Inicial”. Show! Vou fazer commit disso
e empurrar essa nova branch e novamente, nesse momento,
a Vercel já está correndo para fazer o deploy disso
numa URL separada. Então, se eu voltar para o GitHub,
eu vejo a minha alteração, e ao fazer um pull request,
olha que massa que aparece: a Vercel automaticamente
inseriu um comentário explicando que esse pull request
está sendo automaticamente publicado e ao terminar, ela vai substituir esse texto aqui
por uma URL de preview. E dando o refresh aqui, pimba! Dito e feito, apareceu uma URL
única para essa versão do código e que colocando lado a lado, eu posso ver que as duas versões
estão de fato rodando em paralelo. A gente usa essa mesma
estratégia no Brazil API, só que a gente usa o GitHub Actions
para pegar essa URL única e rodar os testes de integração contra ela. Ou seja, a gente não está rodando
os testes contra um ambiente separado de homologação
numa infraestrutura diferente. Estamos rodando os testes contra a
exata mesma estrutura de produção da Vercel ou ao menos a infraestrutura
mais próxima possível de produção. E obviamente, nesses casos você deve
usar variáveis de ambiente diferentes para segurar chaves
e segredos de cada ambiente e tudo isso eu quero mostrar para vocês. Inclusive, várias coisas
ultra importantes de aprender, como as rotas de API que o Next.js fornece
e que é muito poderoso, é animal! Mas antes, um pedido honesto, tá turma? Honesto mesmo. Para eu ter certeza que eu estava ensinando
Next.js e Vercel para vocês do jeito certo, eu comprei um curso gringo,
que não foi barato e turma… Que decepção! A pessoa não teve um décimo do carinho
em construir um material, se comparado ao que eu trouxe neste vídeo. E nem um centésimo
comparado à preocupação em querer que vocês
aprendam genuinamente. Então, se você achar que
esses vídeos aqui valem R$5 e dentro de um mês inteiro esse valor
não vai fazer falta no seu orçamento, considere se tornar um Membro da Turma, porque hoje essas são as pessoas
que estão mais me dando segurança para continuar produzindo conteúdos
nessa qualidade, nesse nível e disponíveis de graça para todo mundo. Considera pelo menos conferir do que
se trata clicando no botão Seja Membro ou no link que está na descrição, que lá eu falo todos os detalhes. Mas, em destaque, eu faço um vídeo extra,
exclusivo toda sexta-feira, onde a gente conversa de tudo o que
não dá para conversar de fora no canal. Eu também estou reconstruindo
a minha linha do tempo para destacar os pontos fundamentais
da minha formação desde criança até adulto. E novamente, você vira patrocinador
de quatro vídeos por mês, produzidos com muito carinho e que são disponibilizados para todos
os programadores do Brasil e afora, incluindo legendas para as
pessoas com problemas auditivos. E a gente ainda tem muito o que aprender
ainda sobre desenvolvimento web moderno, principalmente usando recursos
mais avançados do Next.js e Vercel. Então, para ver a continuação dessa série, clica neste vídeo aqui! Fechado? Valeu.
