Um painel Next.js com metade das requisições

O problema aparecia a cada troca de rota em um painel administrativo feito com Next.js e PostgREST. As páginas voltavam a buscar informações de usuário, pedidos, produtos, precificação e integrações. Cada uma resolvia seu próprio contexto, e chamadas semelhantes se repetiam pelo sistema.

Não havia um erro crítico que impedisse o uso. O painel continuava funcionando, mas essa organização fazia o backend processar trabalho redundante. Também tornava mais difícil entender quais informações eram compartilhadas e quais precisavam ser atualizadas de maneira independente.

Comecei mapeando o fluxo: de onde vinha cada informação, quais chamadas dependiam umas das outras e por quanto tempo cada dado continuava útil. Esse diagnóstico ajudou a separar necessidades que pareciam iguais na interface, mas tinham regras diferentes.

O ponto era descobrir quais informações pertenciam ao contexto inicial do painel e quais tinham seu próprio ciclo de atualização. Reunir tudo em uma única chamada criaria outra dificuldade se dados independentes passassem a depender uns dos outros.

Estruturei um contexto server-side para o bootstrap do painel — a preparação dos dados necessários para começar a usá-lo. Com essa responsabilidade no servidor, o fluxo compartilhado passou a ter um lugar definido na aplicação.

Mantive separadas as chamadas que tinham regras ou ciclos de vida próprios. Na área de precificação, também implementei cache em memória para reaproveitar informações em retornos sucessivos e evitar recomputações desnecessárias.

A mudança juntou duas decisões: organizar melhor quem coordena as chamadas e evitar refazer cálculos quando a informação ainda pode ser aproveitada. O contexto de cada dado foi o critério para decidir onde aplicar cada uma.

Na publicação em que descrevi o trabalho, relatei uma redução de 50% no número de requisições do painel. A experiência do usuário foi mantida, e o backend passou a receber menos trabalho redundante.

Esse percentual se refere às requisições. Ele ajuda a explicar o efeito da refatoração nesse fluxo específico; não deve ser lido como uma redução equivalente de tempo de resposta ou custo de infraestrutura.

A experiência também deu origem a um playbook técnico sobre organização de responsabilidades, Clean Architecture e migração vertical. A ideia da migração vertical é trabalhar em um endpoint por vez, acompanhando seu caminho completo, com critérios de conclusão e uma entrada gradual em produção.

Documentar esse percurso tornou o raciocínio da refatoração compartilhável. O aprendizado que levo é começar pela vida útil e pelas dependências dos dados: elas dão um critério mais claro para decidir o que centralizar, o que manter separado e onde um cache faz sentido.

Leia a publicação original sobre a redução de requisições.