Revelacine

Visão Geral

Revelacine nasceu de um problema bem concreto: acompanhar o mundo do cinema exigia pular entre apps de streaming, listas manuais e sites de catálogo. Eu queria um lugar único onde fosse possível descobrir filmes novos, votar em recomendações, manter uma lista de assistidos e ainda ter noção do tempo total investido - tudo isso com dados atualizados automaticamente, sem depender de input manual o tempo todo.

Usei esse problema como base para um projeto de estudo full-stack com foco em arquitetura de múltiplos serviços. Em vez de um monolito simples, criei três serviços independentes: um frontend em Next.js 13, uma API em Fastify e um bot em Python responsável por sincronizar o catálogo com a API do TMDB e otimizar imagens antes de salvá-las. Cada serviço tem ciclo de deploy próprio e poderia, na prática, escalar separadamente.

Meu papel foi end-to-end: modelagem do domínio (filmes, gêneros, votos, usuários, watchlist), implementação da API REST com Fastify e Prisma, construção do frontend com SSR/CSR híbrido em Next.js, e o design/implementação do bot em Python que cuida tanto da orquestração de jobs quanto do pipeline de imagens. O resultado é um catálogo de filmes que se mantém atualizado de forma contínua, com assets otimizados e uma experiência de navegação fluida.

Como é um projeto solo voltado a aprendizado, o impacto é principalmente técnico: consolidação de uma stack moderna, prática em orquestrar serviços com responsabilidades bem definidas e um laboratório realista para temas como rate limiting, exponential backoff, CORS em produção e otimização de performance em frontend.

Diferencial Principal

O diferencial do Revelacine não é “ser mais um catálogo de filmes”, e sim a forma como ele simula, em um projeto pessoal, um ambiente de produção com múltiplos serviços especializados. O bot de sincronização não é um script acoplado à API: é um serviço Python independente, com scheduler próprio, política de retries com exponential backoff e pipeline de otimização de imagens integrado a um storage S3-compatível (Cloudflare R2).

Outro ponto incomum para um side project é o cuidado com performance de assets e consumo de API externa. Em vez de servir diretamente as imagens brutas do TMDB, o bot faz download, redimensiona, converte para WebP com compressão ajustada e só então publica no bucket R2, evitando reprocesso desnecessário em ciclos posteriores. Do lado da sincronização de dados, cada tipo de job (trending, lançamentos, gêneros) tem sua própria agenda e sua própria política de retry, o que reduz acoplamento e torna a recuperação de falhas mais previsível.

Essa combinação de frontend SSR, API performática em Fastify, bot pesado isolado em Python e pipeline de imagens/CDN próprio é o que torna o projeto interessante como estudo de arquitetura, e não apenas como UI de catálogo.

Arquitetura

• Frontend (Next.js 13 + React 18): Interface pública para descoberta de filmes, detalhes, votos e watchlist. Usa SSR para páginas principais e React Query para hidratação e cache de dados no cliente. Gerencia estado global leve com Zustand (auth, votos, lista de assistidos) e animações com GSAP.
• API (Fastify + Prisma): Serviço Node.js responsável por autenticação (JWT + Google OAuth2), endpoints de filmes, gêneros, votos, usuários e watchlist. Implementa validação de payload com Zod, middlewares de autenticação e paginação/filtragem para o catálogo.
• Bot de sincronização (Python 3.9): Serviço isolado que se comunica diretamente com a API do TMDB e o banco PostgreSQL. Usa APScheduler para orquestrar jobs de trending, lançamentos e gêneros em janelas de tempo diferentes, com retries e exponential backoff.
• Pipeline de imagens (Pillow + Boto3 + Cloudflare R2): Submódulo dentro do bot responsável por baixar posters/backdrops do TMDB, redimensionar, converter para WebP e fazer upload para um bucket R2, retornando URLs de CDN para uso pelo frontend.
• Banco de dados (PostgreSQL + Prisma): Armazena filmes, gêneros, usuários, votos, listas de assistidos e metadados de sincronização. Prisma cuida de migrações, tipagem e acesso aos dados a partir da API.
• Infraestrutura (Docker, Vercel, VPS, GitHub Actions): Frontend deployado em Vercel; API e bot rodando em VPS via Docker. GitHub Actions automatiza build, testes básicos e deploy, além de ter sido o ponto principal de iterações em configuração de CORS e variáveis de ambiente.
• Autenticação e Autorização: Google OAuth2 para login, emissão de JWT para consumo da API pelo frontend, middleware de verificação de token para proteger rotas sensíveis como votos e watchlist.

Destaques Técnicos

• Implementei um sistema de retries com exponential backoff para jobs do bot em Python, evitando saturar a API do TMDB em situações de instabilidade e mantendo a sincronização resiliente a falhas temporárias.
• Modelei um pipeline de imagens que converte posters e backdrops para WebP, com redimensionamento e compressão via Pillow, e publica em Cloudflare R2 via Boto3, permitindo servir assets otimizados em um domínio de CDN próprio.
• Estruturei a API em Fastify com validação de entrada via Zod, autenticação JWT e integração com Google OAuth2, mantendo tipagem end-to-end com TypeScript e Prisma.
• Separei responsabilidades em três serviços independentes (frontend, API e bot), cada um com ciclo de deploy e requisitos de performance distintos, simulando um cenário real de microserviços.
• Resolvi problemas práticos de CORS em produção ao expor a API para o frontend em Vercel, implementando lógica de validação baseada em hostname em vez de listas estáticas frágeis.
• Organizei a sincronização de catálogo com APScheduler usando múltiplos cron jobs (trending a cada 10 minutos, lançamentos a cada 30 minutos e gêneros a cada hora), com deduplicação e max_instances=1 para evitar corridas e sobreposição de execuções.