Engenharia do Caos para TypeScript: como fortalecer sua aplicação

Quando seu serviço TypeScript encontra o caos

Imagine: sua aplicação TypeScript funciona perfeitamente — os testes passam, o deploy é bem-sucedido, os usuários estão satisfeitos. Mas então chegam 3 horas da manhã, e o cluster Redis decide "tirar uma soneca". Ou a CDN começa a retornar erros 503. Ou, ainda mais divertido, um pacote de rede se perde em algum lugar entre os continentes.

Nesse momento, seu código TypeScript cuidadoso, escrito com carinho, pode se comportar como um gato assustado. Ou como um super-herói. Tudo depende se você o treinou para enfrentar o caos de frente.

Engenharia do Caos não é sobre quebrar a produção. É sobre aprender a quebrar corretamente. E o TypeScript, com sua tipagem forte e abstrações poderosas, é um excelente campo de treinamento para isso.

O que é engenharia do caos de verdade?

Engenharia do Caos é a disciplina de experimentar em um sistema distribuído para identificar seus pontos fracos antes que os usuários o façam. No contexto de aplicações TypeScript, isso significa:

\n
• Injeção sistemática de falhas — desligamento de serviços, atrasos, erros de rede
\n
• Observação do comportamento — como seu código reage a imprevistos
\n
• Automação de experimentos — para repeti-los regularmente
\n
• Melhoria da arquitetura — com base nos dados obtidos
\n

A regra principal: você não deve descobrir um problema através de um usuário irritado. É melhor que seu "destruidor" automatizado descubra em um ambiente controlado.

Por que o TypeScript é ideal para engenharia do caos?

TypeScript não é apenas um superset do JavaScript. É a capacidade de escrever código que é previsível mesmo no caos. Veja por quê:

\n
• Tipagem forte — você sabe exatamente quais dados entram e saem. Mas e se, em vez de um número, vier undefined? Testes de caos verificarão isso.
\n
• Assincronicidade — Promise, async/await, Observable — tudo isso pode "quebrar" de maneiras interessantes com problemas de rede.
\n
• Ecossistema — Jest, Mocha, Playwright — ferramentas prontas para integrar cenários de caos.
\n

Exemplo prático: implementando caos em uma aplicação Express

Vamos imaginar que temos uma aplicação Express simples em TypeScript que consulta uma API externa para obter dados meteorológicos. Queremos testar como ela se comportará se essa API ficar indisponível.

Passo 1: Escrevendo um serviço comum

// weather.service.ts\ninterface WeatherResponse {\n    temperature: number;\n    humidity: number;\n    condition: string;\n}\n\nclass WeatherService {\n    async getWeather(city: string): Promise<WeatherResponse> {\n        const response = await fetch(`https://api.weather.com/v1/${city}`);\n        \n        if (!response.ok) {\n            throw new Error(`Weather API error: ${response.status}`);\n        }\n        \n        return response.json() as Promise<WeatherResponse>;\n    }\n}\n\nexport const weatherService = new WeatherService();

Passo 2: Adicionando um controlador com proteção

// weather.controller.ts\nimport { Request, Response } from 'express';\nimport { weatherService } from './weather.service';\n\nclass WeatherController {\n    async getWeatherHandler(req: Request, res: Response) {\n        const { city } = req.params;\n        \n        try {\n            const weather = await weatherService.getWeather(city);\n            res.json(weather);\n        } catch (error) {\n            // Registramos o erro\n            console.error(`Falha ao buscar clima para ${city}:`, error);\n            \n            // Retornamos uma resposta de fallback\n            res.status(503).json({\n                error: 'Serviço temporariamente indisponível',\n                fallback: {\n                    tempe