TypeScript de ponta a ponta: reduzindo bugs em produção com tipagem unificada entre front, app e back

Um dev renomeia telefone para celular na API. O site continua mandando telefone, o app também. Nenhum erro aparece até um cliente reclamar que o cadastro "não salva". Esse bug não é falta de atenção: é falta de um contrato que todos compartilham.

A ideia

Quando web, app e backend são escritos em TypeScript, os tipos dos dados que trafegam entre eles podem viver num lugar só. Mudou o contrato, o compilador aponta cada tela que precisa de ajuste — antes do deploy.

Como estruturar

• Um pacote compartilhado (num monorepo) com esquemas e tipos: Cliente, Pedido, RespostaPaginada.
• Esquemas Zod como fonte da verdade: o mesmo esquema valida no servidor e no formulário e gera o tipo — veja Validação rigorosa de dados: prevenindo falhas de segurança e dados inconsistentes com Zod e TypeScript.
• Front, app e API importam do mesmo pacote. Nada de copiar interfaces à mão.

// packages/contratos/cliente.ts
export const ClienteSchema = z.object({ nome: z.string(), celular: z.string() })
export type Cliente = z.infer<typeof ClienteSchema>

O que você ganha

• Bugs de contrato viram erros de compilação.
• Refatorações deixam de dar medo.
• O app React Native aproveita a mesma lógica do site — tema de App e site com a mesma base de código: o que dá para compartilhar.

E se a API for pública?

Para parceiros que não usam TypeScript, gere documentação a partir dos mesmos esquemas e versione a API com cuidado, como em Versionamento de API: mudar sem quebrar o app de ninguém.

Cuidados

• Compartilhe contratos, não regras de negócio do servidor — o front não precisa saber como o desconto é calculado.
• Proíba any. Um único any no caminho apaga a garantia.

Usamos essa arquitetura nos sistemas, apps e no WOCOM Hub. Conte o seu cenário.