Pitch: Meu projeto feito em Next.js 16.2.9

Olá pessoal do TabNews.

Há pouco tempo lancei um projeto pessoal chamado Despencando, uma plataforma que monitoriza e mostra quedas reais de preços em lojas de tecnologia. Como a comunidade aqui valoriza bastante discussões sobre infraestrutura, decidi escrever um pouco sobre como montei a stack tecnológica e os problemas que tive de resolver no processo, sem entrar na lógica do negócio.

Aqui fica um resumo de como as coisas estão estruturadas:

A base de dados: PostgreSQL
A primeira decisão foi garantir que a base de dados era a fonte única da verdade. Escolhi o PostgreSQL. No início da estruturação, a tentação é deixar alguma lógica espalhada, mas aprendi que toda a informação (histórico, variações, estado da oferta) tem de estar consolidada no Postgres. Se o dado não está validado e gravado lá, o frontend simplesmente não o conhece.

Backend: FastAPI
Para a API principal e o painel de administração, decidi usar FastAPI. Como os scrapers já são desenvolvidos em Python, manter a mesma linguagem facilitou bastante o ecossistema.
O FastAPI funciona essencialmente como um filtro rigoroso: ele recebe os dados em bruto (JSON) enviados pelos scrapers, faz a auditoria para confirmar que a oferta é válida e só depois grava na base de dados. O Swagger automático que ele gera também me poupou horas de documentação interna.

O desafio do Frontend: Next.js e SEO
O projeto depende quase a 100% de SEO e indexação orgânica. Fazer uma SPA tradicional em React estava fora de questão. Fui para o Next.js para garantir o Server-Side Rendering (SSR).

O maior problema técnico aqui foi a gestão do cache. Imaginem uma promoção que esgota rapidamente, mas o Next.js continua a servir a página em cache com o preço antigo. Para resolver isto, tive de montar um sistema em que o FastAPI avisa ativamente o Next.js para invalidar o cache de rotas específicas (revalidação on-demand) sempre que um preço muda. Deu bastante trabalho a estabilizar, mas evitou que a base de dados fosse bombardeada com pedidos desnecessários.

Isolar o problema: A extração de dados
Se há coisa que aprendi é que scrapers falham, bloqueiam e consomem recursos de forma imprevisível. Por isso, isolei totalmente essa responsabilidade.

A extração não corre no mesmo ambiente do site. São scripts modulares que vão às lojas, padronizam a informação e enviam um payload fechado para a API principal. Um detalhe importante desta arquitetura: os scrapers fazem o download das imagens originais. Desisti de usar hotlinks das lojas porque os links quebravam com frequência e prejudicavam a interface.

Infraestrutura e Deploy
Não inventei muito na infraestrutura para o dia zero:

• Servidor: Uma VPS a correr Ubuntu 24.04.
• Web Server/Proxy: Caddy. Para quem ainda usa Nginx em projetos pequenos e odeia configurar certificados HTTPS à mão, recomendo vivamente testarem o Caddy. Ele atua como reverse proxy para o Next.js e para o FastAPI, e renova os certificados automaticamente.
• Processos: PM2 para manter a aplicação Next.js a correr em background.
• DNS: Cloudflare na frente.

No fundo, o segredo para manter o projeto escalável foi separar as responsabilidades: quem extrai os dados não mexe diretamente na base de dados; e quem serve as páginas aos utilizadores não faz validações pesadas.