⚡ Deploy Moderno

Deploy e o ato de pegar seu projeto e coloca-lo num servidor publico, com um endereco que qualquer pessoa acessa. A Vercel e uma plataforma que faz isso de forma quase automatica.

Codigo no seu computador so voce ve. Deploy e o que transforma o projeto em algo real e compartilhavel. A Vercel torna esse passo simples e gratuito.

A Vercel e ideal para sites e apps modernos (React, Next.js, HTML). Ela observa seu repositorio e refaz o deploy a cada mudanca, sem comando manual.

O cadastro na Vercel usando sua conta do GitHub e a autorizacao para a Vercel enxergar seus repositorios.

E a ponte que liga onde seu codigo vive (GitHub) a onde ele sera publicado (Vercel). Sem essa conexao, nao ha deploy automatico.

Use "Sign up with GitHub" para criar a conta ja conectada. Autorize so os repositorios que voce quer publicar. O plano gratuito (Hobby) basta para comecar.

O passo de importar um repositorio na Vercel e clicar em "Deploy". Em segundos, seu projeto ganha um endereco publico funcionando.

E o momento "no ar" da Trilha 2: ver seu site rodando num link real prova que o ciclo de deploy funciona de ponta a ponta.

A Vercel detecta o tipo do projeto sozinha. Voce recebe um endereco projeto.vercel.app. A partir dai, cada git push refaz o deploy.

A cada branch ou pull request, a Vercel cria um deploy de "preview": uma copia do site com endereco proprio, separada da versao de producao.

Permite testar uma mudanca num link real antes de mexer no site principal. Voce mostra a novidade para alguem sem riscos para a versao no ar.

A branch main vira producao; as outras viram previews. Cada preview tem URL unica e some quando a branch e removida.

O painel de configuracoes da Vercel: comando de build, pasta raiz do projeto, dominios e o botao de refazer (redeploy) um deploy.

Projetos crescem e precisam de ajustes. Saber onde mexer evita aquele "funciona no meu PC, mas quebra no deploy".

Na maioria dos casos os padroes ja servem. Mude o "Root Directory" se o projeto esta numa subpasta. O "Redeploy" repete o ultimo deploy.

Trocar o endereco padrao projeto.vercel.app por um dominio proprio que voce comprou, como seusite.com.

Um dominio proprio passa profissionalismo e e mais facil de divulgar. A Vercel cuida do HTTPS automaticamente, de graca.

Adicione o dominio em "Domains" e aponte o DNS conforme a Vercel indicar. O certificado HTTPS (cadeado) e gerado sozinho.

Um banco de dados e um lugar organizado para guardar informacao de forma permanente: usuarios, pedidos, mensagens. Pense numa planilha gigante e confiavel que muitos programas podem ler e escrever ao mesmo tempo.

Quase todo app de verdade precisa lembrar de algo entre uma visita e outra. Sem banco, tudo se perde quando a pagina fecha.

Os dados ficam em tabelas (linhas e colunas). O Supabase usa PostgreSQL, um banco poderoso e gratuito, por baixo dos panos.

O passo de criar uma conta, abrir um novo projeto e deixar o Supabase provisionar um banco PostgreSQL pronto para uso.

Montar um banco do zero costumava ser complicado. O Supabase entrega isso em poucos cliques, sem voce instalar nada.

Escolha uma regiao perto de voce e guarde a senha do banco com cuidado. O plano gratuito ja serve para aprender e prototipar.

A organizacao do banco: cada tabela guarda um tipo de coisa (ex.: "usuarios"), as colunas sao os campos (nome, email) e o tipo define o que cabe em cada coluna (texto, numero, data).

Uma boa estrutura evita bagunca e erros. Definir tabelas e tipos certos no inicio poupa muita dor de cabeca depois.

Crie tabelas pelo "Table Editor" visual. Tipos comuns: text, int, bool, timestamp. Toda linha tem um id unico.

As duas acoes mais comuns num banco: inserir (gravar uma nova linha) e consultar (buscar linhas que atendem a um criterio). E o "escrever e ler" do banco.

Todo app vive disso: salva o que o usuario digita e mostra de volta o que ja foi salvo. Sem inserir e consultar, o banco fica parado.

Voce pode inserir pela tela ou por codigo. A linguagem por tras e o SQL (insert, select), mas o Supabase deixa fazer tudo de forma visual tambem.

Assim que voce cria uma tabela, o Supabase gera sozinho uma API: enderecos prontos para o seu site ler e gravar dados no banco pela internet.

Normalmente seria preciso programar um servidor inteiro para isso. Ter a API de graca conecta seu frontend ao banco em minutos.

Cada projeto tem uma URL e uma chave (anon key). A biblioteca supabase-js facilita as chamadas. Esse e o gancho para o modulo de APIs.

O sistema pronto do Supabase para cadastro e login de usuarios: email e senha, ou entrar com Google e GitHub, sem voce programar isso do zero.

Login seguro e dificil de fazer certo. Usar uma solucao pronta evita falhas graves e te deixa focar no resto do app.

O Supabase gerencia senhas e sessoes. Com regras de acesso (RLS), cada usuario so enxerga os proprios dados. Ative os provedores na aba Authentication.

API e um conjunto de enderecos por onde um programa pede informacao a outro. Pense num garcom: voce faz um pedido, ele leva a cozinha e traz o prato; voce nao precisa saber como a cozinha funciona.

Tudo na web moderna conversa por API: clima, mapas, pagamentos, seu banco no Supabase. Entender API e entender como apps se conectam.

Voce envia uma requisicao a uma URL e recebe uma resposta, quase sempre em formato JSON. A maioria das APIs web fala por HTTP.

Os quatro verbos basicos de uma API: GET le, POST cria, PUT atualiza e DELETE apaga. Cada um descreve a intencao do pedido.

Usar o verbo certo deixa a API previsivel e organizada. E o vocabulario padrao que todo servico web entende.

Lembre pelo CRUD: Create=POST, Read=GET, Update=PUT, Delete=DELETE. GET nunca deve mudar dados; POST e PUT enviam um corpo com a informacao.

Duas formas de testar uma API sem escrever um app: o curl faz a chamada pelo terminal; o Thunder Client e uma extensao do VS Code com tela visual para isso.

Antes de ligar a API ao seu site, e essencial conferir se ela responde como esperado. Testar primeiro economiza horas de depuracao.

curl -X GET url faz a chamada mais simples. O Thunder Client guarda suas requisicoes e mostra a resposta formatada. Veja sempre o codigo de status.

Usar o JavaScript do seu site para chamar uma API e mostrar o resultado na tela. A ferramenta padrao do navegador para isso e o fetch.

E o que torna um site "vivo": ele busca dados na hora e atualiza a pagina sem recarregar. Esse e o coracao de qualquer app dinamico.

fetch(url) retorna uma promessa; use await e .json() para ler a resposta. Chamadas sao assincronas: o codigo espera a resposta chegar.

APIs abertas que qualquer um pode usar para buscar dados prontos: previsao do tempo, endereco a partir do CEP (ViaCEP), cotacao de moedas e muito mais.

Sao a forma mais facil de praticar: voce ja recebe dados reais sem montar um servidor. Da para enriquecer seu app com pouco esforco.

Algumas pedem uma chave (API key) gratuita; outras, como a ViaCEP, sao abertas. Leia a documentacao para saber a URL e o formato da resposta.

A pratica de prever que a API pode falhar (internet caiu, dado nao existe, servico fora do ar) e mostrar uma mensagem clara em vez de quebrar o app.

No mundo real, requisicoes falham. Um app que trata erros bem parece profissional; um que trava na primeira falha frustra o usuario.

Status 200 e sucesso; 404 nao encontrado; 500 erro do servidor. Use try/catch e cheque response.ok antes de usar os dados.

Variaveis de ambiente sao valores guardados fora do codigo, como uma chave de API ou senha do banco. O programa as le na hora de rodar, sem que elas estejam escritas no projeto.

Permitem separar o "como o app funciona" (codigo) do "com quais segredos ele funciona" (configuracao). Trocar um segredo nao exige mexer no codigo.

Sao pares NOME=valor. O mesmo codigo roda diferente em cada ambiente (seu PC, producao) so trocando as variaveis.

Um arquivo chamado .env na raiz do projeto onde voce escreve suas variaveis, uma por linha, para usar enquanto desenvolve no seu computador.

E a forma padrao de guardar segredos durante o desenvolvimento, sem escrever a chave direto no codigo que vai para o GitHub.

Formato CHAVE=valor, sem espacos. O .env precisa ir no .gitignore (visto na Trilha 1) para nunca subir.

O painel da Vercel onde voce cadastra as mesmas variaveis do .env, mas para o site que esta no ar. Como o .env nao sobe, a Vercel precisa receber os segredos por aqui.

Sem isso, seu site publicado nao consegue acessar o banco ou as APIs. E o passo que liga o deploy aos seus segredos com seguranca.

Adicione em "Settings → Environment Variables". Da para separar por ambiente (Production, Preview). Apos mudar, refaca o deploy.

O GitHub Actions roda tarefas automaticas (testes, deploy) a cada push. Os "Secrets" sao onde voce guarda chaves para essas tarefas usarem com seguranca.

Automacoes tambem precisam de segredos, mas nunca devem te-los escritos no arquivo de configuracao. Os Secrets resolvem isso.

Cadastre em "Settings → Secrets and variables → Actions". No fluxo, voce os acessa por ${{ secrets.NOME }}. Eles aparecem mascarados nos logs.

A regra de ouro: senhas, chaves de API, tokens e o proprio .env nunca devem ir para o GitHub. Uma vez no historico, ficam la para sempre.

Vazar um segredo num repositorio publico e um dos erros mais comuns e perigosos: bots varrem o GitHub atras de chaves para usar indevidamente.

Sempre coloque .env no .gitignore. Confira com git status antes do commit. Se vazou, considere a chave comprometida e troque-a.

Rotacao e o ato de gerar uma chave nova e descartar a antiga, periodicamente ou quando ha suspeita de vazamento. E como trocar a fechadura por seguranca.

Chaves antigas que ja circularam sao um risco. Rotacionar limita o estrago: mesmo que uma chave vaze, ela logo deixa de funcionar.

Gere a nova chave no servico, atualize em todos os lugares (.env, Vercel, Actions) e so depois revogue a antiga, para nao quebrar o app no meio.