Finanças Pessoais
Web app de controle financeiro pessoal: registre receitas e despesas, categorize
cada lançamento e acompanhe receita, despesa e saldo do mês em uma única tela.
Construído a partir do PRD PRD_FinancasPessoais_Aula41.pdf.
Funcionalidades
- Landing page pública com a proposta do produto.
- Login e cadastro por e-mail e senha (Supabase Auth), com rotas protegidas.
- Dashboard com cards de Receita, Despesa e Saldo, rosca de composição por
categoria (receitas e despesas) e evolução dos últimos 6 meses.
- CRUD de transações: criar, editar e excluir, com descrição, valor, data,
tipo e categoria.
- Categorias pré-definidas: Alimentação, Transporte, Moradia, Lazer, Saúde,
Educação, Salário, Freelance e Outros.
- Busca e filtros por descrição, mês, ano, categoria e tipo — tudo refletido
na URL, então um filtro é compartilhável.
- Exportar CSV do que está filtrado na tela, no formato que o Excel pt-BR abre
direto (separador
;, vírgula decimal e BOM UTF-8).
- Responsivo e com tema claro/escuro.
Stack
| Camada | Tecnologia |
|---|
| Frontend | Next.js 16 (App Router), React 19, TypeScript |
| Estilos | Tailwind CSS v4, componentes no padrão shadcn/ui |
| Gráficos | Recharts |
| Backend | Supabase (PostgreSQL + Auth + Row Level Security) |
| Deploy | Vercel |
Não há backend próprio: o app fala direto com o Supabase, e o isolamento entre
contas é garantido por RLS no banco.
Como rodar
1. Crie o projeto no Supabase
- Crie um projeto em supabase.com.
- Abra SQL Editor e rode o conteúdo de
supabase/migrations/0001_init.sql.
Ele cria a tabela transactions, os índices e as políticas de RLS.
- Em Project Settings → API, copie a Project URL e a chave anon public
(nos projetos novos ela aparece como publishable key,
sb_publishable_...;
serve no mesmo lugar).
Duas armadilhas do painel
"Last migration: No migrations" não quer dizer que faltou rodar o SQL. Esse
indicador só conta migrations aplicadas pela CLI do Supabase. SQL colado no
editor não aparece ali. Para saber de verdade se a tabela existe:
curl -s "$NEXT_PUBLIC_SUPABASE_URL/rest/v1/transactions?select=id&limit=1" \
-H "apikey: $NEXT_PUBLIC_SUPABASE_ANON_KEY"
[] significa que a tabela existe e a RLS está filtrando (é o esperado sem
login). Um PGRST205 Could not find the table significa que o SQL não rodou.
"Enable Email provider" e "Confirm email" ficam colados. Em
Authentication → Sign In / Providers → Email os dois toggles são vizinhos, e
desligar o de cima por engano derruba o login inteiro — o cadastro passa a
responder 400 email_provider_disabled. O de cima fica ligado; o de baixo é
o que controla a exigência de confirmação.
Confirmação de e-mail
Com Confirm email ligado (o padrão, e o certo para uso real), o cadastro só
vira sessão depois do clique no link, que volta para /auth/callback. O app já
trata isso: mostra "Conta criada. Confira seu e-mail para confirmar o cadastro."
Configure um SMTP próprio antes de abrir para outras pessoas. O SMTP padrão
do Supabase é só para desenvolvimento: tem limite baixo de envios por hora e,
em vários planos, só entrega para membros do projeto. Na prática, alguém de
fora tenta se cadastrar e o e-mail nunca chega. Configure em
Authentication → Emails → SMTP Settings (Resend, SendGrid, Amazon SES).
2. Configure as variáveis
cp .env.example .env.local
Preencha:
SUPABASE_URL=https://SEU-PROJETO.supabase.co
SUPABASE_ANON_KEY=sua-chave-anon-ou-publishable
Repare que não há prefixo NEXT_PUBLIC_. Isso é proposital: no Next, toda
variável NEXT_PUBLIC_ é inlinada no JavaScript que o navegador baixa. Como
nenhum componente de cliente fala com o Supabase — autenticação e CRUD passam
por Server Actions —, as credenciais ficam só no servidor. O
src/lib/supabase/env.ts importa server-only, então o build quebra se alguém
tentar usá-las a partir do navegador.
3. Suba o app
npm install
npm run dev
Abra http://localhost:3000.
Scripts
| Comando | O que faz |
|---|
npm run dev | Servidor de desenvolvimento |
npm run build | Build de produção |
npm run start | Sobe o build |
npm run lint | ESLint |
Testes
npm run test:rls # RLS e constraints, direto no banco
npm run test:e2e # interface inteira num Chrome headless (precisa do npm run dev)
O test:rls cria dois usuários e prova que um não alcança os dados do outro. O
test:e2e faz o caminho completo pela tela: cadastro, três lançamentos, conferência
dos totais, exportação do CSV, os filtros, edição, exclusão e logout.
Os dois precisam de Confirm email desligado enquanto rodam, e criam usuários
teste-*@example.com que você apaga depois em Authentication → Users. Detalhes
em tests/README.md.
Segurança
| Camada | O que protege |
|---|
| Credenciais só no servidor | Nenhuma chave do Supabase vai para o bundle do navegador |
| Row Level Security | O banco recusa acesso aos dados de outra conta, mesmo com a chave em mãos |
| Server Actions | Valor, categoria, tipo e descrição são validados no servidor, não só no formulário |
redirectTo restrito | Só aceita caminhos internos, para não virar redirecionamento aberto |
| Cabeçalhos HTTP | nosniff, X-Frame-Options: DENY, Referrer-Policy, Permissions-Policy, HSTS |
Para conferir que nenhuma credencial vazou para o navegador depois de mexer no código:
npm run build
grep -rl "supabase.co" .next/static/ || echo "nenhuma credencial no bundle"
Duas notas sobre chaves:
여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗
