01 · Compras corporativas
Um quadro comparativo em que dá para confiar
Um BFF em NestJS que reúne dados de propostas e fornecedores vindos de vários serviços em uma visão confiável — e se recusa a apresentar uma comparação incompleta como válida.
- Empresa
- Stratesys
- Cargo
- Desenvolvedor Full Stack Sênior
- Período
- 2026 — atual
- Stack
- NestJS
- Next.js
- TypeScript
- Server Actions
- Jest
01 · O problema
Em compras corporativas, o comprador compara propostas de fornecedores lado a lado antes de decidir a premiação. Os dados dessa tela vêm de serviços diferentes: propostas de um lado, fornecedores de outro, regras do processo e permissões de um terceiro. Uma comparação que perde um fornecedor sem avisar — ou mostra propostas sem o fornecedor correto — não é só um bug. Pode levar a uma decisão comercial errada.
02 · O que eu fiz
- Desenvolvi o endpoint, o controller e a camada de serviço do BFF em NestJS. Ele valida se o processo de compra existe e se o usuário tem acesso, busca as propostas e seus fornecedores e devolve um contrato pensado para a interface.
- Tratei propostas incompletas e diferentes estados de negociação na camada de transformação, para que os componentes React não precisem conhecer o comportamento de cada serviço.
- Tratei falhas e timeouts de dependências essenciais como erros controlados, com logs estruturados e correlation IDs para investigação, e um estado de erro claro com opção de tentar novamente na interface.
- Implementei os fluxos de confirmação de premiação em React e Next.js, mapeando dados tipados dos formulários para os contratos da API nos cenários simples e com encaminhamento para aprovação, com Server Actions centralizando chamadas e tratamento de erros.
- Escrevi testes unitários para as transformações e para erros e timeouts das integrações — incluindo a garantia de que uma comparação inconsistente nunca seja apresentada como válida.
03 · A decisão principal
Falhar com clareza em vez de comparar dados parciais.
Propostas e fornecedores só fazem sentido juntos. Quando uma dependência essencial falha, o BFF devolve um erro controlado em vez de exibir o que chegou. É trocar a indisponibilidade temporária de uma tela pela integridade da decisão que ela apoia — a escolha certa para esse fluxo, não uma regra para toda API.
04 · Diagrama interativo
Ilustração original da ideia de engenharia — não é uma captura do produto.
Como a comparação é montada
Todos os dados essenciais chegaram. O BFF valida o acesso, associa cada proposta ao seu fornecedor e devolve um contrato tipado para a interface.
05 · O que mudou
A composição dos dados passou a viver em um único lugar no backend. A interface ficou focada em apresentação e interação, os contratos ficaram mais fáceis de evoluir e os estados de falha mantêm seu significado: se a comparação está na tela, os dados essenciais estão completos.
06 · Escopo, com transparência
Minha contribuição: o endpoint do BFF, as integrações, transformações, tratamento de erros e testes; a interface de confirmação de premiação e seu mapeamento para a API. A API de premiação e o restante da plataforma são trabalho do time. Não há métricas de SLA ou incidentes atribuídas.