Navegação em Árvore com Sincronização Otimista

Contexto

Pela BairesDev, trabalhei como Engenheiro Frontend Sênior em uma plataforma SaaS orientada por IA — um produto que analisa páginas web e documentos e gera insights estruturados a partir deles. Este estudo cobre a arquitetura e o raciocínio, não o produto.

O problema central de frontend era organização em escala. Usuários acumulavam grandes coleções de documentos analisados, e o produto precisava de uma hierarquia real: pastas e arquivos aninhados, drag and drop e operações recursivas — mover uma pasta move tudo abaixo dela; excluir uma remove a subárvore. Cada uma dessas operações precisava parecer imediata enquanto o trabalho real acontecia pela rede. O mesmo código também carregava a monetização da plataforma: fluxos de assinatura e billing que precisavam estar corretos antes de rápidos. Liderei a arquitetura de frontend desse trabalho.

Decisões

Tratar a árvore como estado de servidor, não estado de UI. A hierarquia vive no cache do React Query como fonte única de verdade, e todos os componentes renderizam a partir dele. A alternativa — espelhar a árvore no estado local dos componentes — é mais simples no primeiro dia e perde sincronização assim que uma operação recursiva toca nós em dois lugares ao mesmo tempo. Centralizar no cache tornou invalidação e sincronização em segundo plano mecânicas, não improvisadas.

Otimista primeiro, reconciliação depois. Ao arrastar uma pasta, a UI confirma a mudança imediatamente; o React Query sincroniza com o servidor em segundo plano e reverte a árvore se a mutação falhar. A troca é real: rollback de uma operação recursiva é mais difícil que um loading, porque uma movimentação que falha precisa restaurar uma subárvore inteira, não uma linha. Aceitamos essa complexidade porque bloquear todo arraste por uma ida e volta de rede fazia o produto parecer quebrado mesmo quando funcionava. A responsividade percebida melhorou cerca de 34% após o trabalho de UI otimista.

SSR/CSR híbrido em vez de escolher um lado. Next.js renderiza no servidor as superfícies públicas relevantes para SEO; o workspace autenticado roda como código de aplicação renderizado no cliente, carregado sob demanda e dividido em chunks para manter o payload inicial pequeno. Dois modos de renderização no mesmo código exigem disciplina sobre onde os dados carregam, mas a separação melhorou carga inicial e visibilidade em busca sem arrastar a árvore interativa por idas e voltas do servidor.

Comprar o seguro antes de precisar dele. Operações recursivas somadas a rollback otimista criam uma superfície grande de casos de borda, então levei a cobertura de testes unitários de frontend a aproximadamente 80% com Jest e TDD. TDD cobra velocidade na semana em que é adotado e devolve isso a cada semana seguinte.

Impacto

Os números que podem ser afirmados: a responsividade percebida melhorou aproximadamente 34% após o trabalho de UI otimista e a cobertura de testes unitários alcançou cerca de 80%, com queda correspondente de regressões chegando à produção. Qualitativamente, a arquitetura híbrida melhorou performance de carga inicial e SEO, e os fluxos de assinatura e billing do Stripe — construídos de ponta a ponta, APIs e webhooks — deram à plataforma receita recorrente sobre processamento seguro de pagamentos. Além das features, mentorei engenheiros frontend e conduzi treinamento estruturado para o programa interno de estágio.

Notas de stack

React e TypeScript formam o sistema de árvore; a API dos componentes usa o sistema de tipos para manter estruturas recursivas corretas. React Query cuida de cache, invalidação e sincronização em segundo plano — é por isso que updates otimistas continuam tratáveis em vez de virar máquinas de estado manuais. Next.js fornece a divisão híbrida SSR/CSR, com lazy loading e code-splitting trabalhando na carga inicial. Jest sustenta a suíte unitária. APIs e webhooks Stripe conduzem assinaturas e billing. Os contratos de API com o backend foram definidos entre GraphQL e REST, melhorando consistência de dados entre a UI e os serviços.