Como Eu Programo e Hospedo Sites da Forma Mais Moderna que Existe [GUIA DEFINITIVO]

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.