Ficha Técnica
Papel
Criador e desenvolvedor
Stack
Todo app de tarefas resolve o dia. Calendário resolve a semana. Metas resolvem o trimestre. O problema é que essas três camadas vivem em apps diferentes — e o Pulse nasceu para juntá-las: tarefas com recorrência de verdade, um calendário que mescla suas tarefas com os eventos do Google Calendar, e metas com KPIs acompanhados em gráfico.
Como funciona
- Tarefas diárias e semanais com prioridade, notas, tags e — o detalhe que muda tudo — rollover: o app detecta o que ficou incompleto ontem e pergunta o que fazer (concluir, mover pra hoje, mover pra semana, descartar). Nada some silenciosamente.
- Recorrência avançada: padrões diários/semanais/mensais/anuais com intervalo, dias da semana, fim por data ou por N ocorrências — com edição "só esta" ou "todas as futuras", como um calendário de verdade.
- Calendário unificado: tarefas aparecem como eventos coloridos por prioridade lado a lado com os eventos de múltiplas contas do Google Calendar, em visões de mês, semana e dia.
- Metas e KPIs: metas quantitativas/qualitativas por timeframe (anual → semanal), registros de KPI com tendência, média e gráficos.
- Local-first: sem login, tudo funciona em
localStorage. Ao entrar com Google, os dados locais migram automaticamente para o Firestore — e passam a sincronizar em tempo real entre dispositivos.
Arquitetura
Visão de componentes e infraestrutura:
Fluxo do OAuth com PKCE (sem segredo no front):
Decisões técnicas que valem a pena contar
OAuth sem segredo no front. Integrar Google Calendar num SPA esbarra num problema clássico: a troca code → tokens exige o client_secret, que não pode viver no browser. A solução: o front gera o par PKCE (Web Crypto, SHA-256) e delega a troca a uma Cloud Function, onde o secret mora — o que também habilita refresh_token persistente para renovação silenciosa.
Contornando limitação do Google Identity Services. O GIS não suporta PKCE nativamente no fluxo de code. O workaround: sobrescrever o requestCode do client para abrir manualmente o popup de autorização com os parâmetros PKCE na URL, e detectar o retorno por polling — feio por fora, correto por dentro.
Sincronização sem race condition. Buscas concorrentes de eventos podiam se sobrescrever (o usuário troca de mês rápido). Um contador de versão incremental descarta respostas obsoletas; tokens expirados disparam refresh silencioso por conexão, e um 401 num calendário não aborta o lote dos demais.
O clássico bug de fuso, evitado por design. Datas são armazenadas como YYYY-MM-DD e parseadas manualmente como data local — new Date('2026-01-15') interpreta UTC e joga sua tarefa pra véspera dependendo do fuso. Todo o app passa longe dessa armadilha.
Stack
React 18 + Vite · TypeScript · Firebase (Auth, Firestore, Cloud Functions) · Google Calendar API v3 · TanStack Query · shadcn/ui + Tailwind · Recharts · PWA com service worker versionado · Vitest + Cypress.
Status
Em produção e em uso diário (v2.x), com testes unitários e e2e. Google Calendar é somente leitura por enquanto — escrever eventos de volta e o provider Supabase (já abstraído nas interfaces) são os próximos capítulos.
Curtiu o projeto?
Se quiser conversar sobre esse projeto, arquitetura ou uma oportunidade de trabalho, é só me chamar. 🚀
contato@racoelho.com.br