Ingeniería del caos para TypeScript: cómo endurecer tu aplicación

Cuando tu servicio TypeScript se encuentra con el caos

Imagina: tu aplicación TypeScript funciona perfectamente: las pruebas pasan, el despliegue se realiza, los usuarios están contentos. Pero llegan las 3 de la madrugada y el clúster de Redis decide "echarse una siesta". O la CDN empieza a devolver errores 503. O, aún más divertido, un paquete de red se pierde en algún lugar entre continentes.

En ese momento, tu código ordenado en TypeScript, escrito con cariño, puede comportarse como un gato asustado. O como un superhéroe. Todo depende de si lo has entrenado para enfrentar el caos cara a cara.

La ingeniería del caos no se trata de romper la producción. Se trata de aprender a fallar correctamente. Y TypeScript, con su tipado estricto y sus potentes abstracciones, es un excelente campo de pruebas para dicho entrenamiento.

¿Qué es realmente la ingeniería del caos?

La ingeniería del caos es la disciplina de experimentar con un sistema distribuido para identificar sus puntos débiles antes de que lo hagan los usuarios. En el contexto de las aplicaciones TypeScript, esto significa:

\n
• Introducción sistemática de fallos — desconexión de servicios, retrasos, errores de red
\n
• Observación del comportamiento — cómo reacciona tu código ante lo inesperado
\n
• Automatización de experimentos — para repetirlos regularmente
\n
• Mejora de la arquitectura — basada en los datos obtenidos
\n

La regla principal: no debes enterarte del problema por un usuario enfadado. Es mejor que lo descubra tu "destructor" automatizado en un entorno controlado.

¿Por qué TypeScript es ideal para la ingeniería del caos?

TypeScript no es solo un superconjunto de JavaScript. Es la posibilidad de escribir código que sea predecible incluso en el caos. He aquí por qué:

\n
• Tipado estricto — sabes exactamente qué datos entran y salen. Pero, ¿y si en lugar de un número llega undefined? Las pruebas de caos lo verificarán.
\n
• Asincronía — Promise, async/await, Observable — todo esto puede "romperse" de formas interesantes ante problemas de red.
\n
• Ecosistema — Jest, Mocha, Playwright — herramientas listas para integrar escenarios de caos.
\n

Ejemplo práctico: introduciendo caos en una aplicación Express

Imaginemos que tenemos una aplicación Express simple en TypeScript que consulta una API externa para obtener datos meteorológicos. Queremos comprobar cómo se comportará si dicha API deja de estar disponible.

Paso 1: Escribamos un servicio normal

// 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();

Paso 2: Añadamos un controlador con protección

// 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 el error\n            console.error(`Failed to fetch weather for ${city}:`, error);\n            \n            // Devolvemos una respuesta de respaldo\n            res.status(503).json({\n                error: 'Service temporarily unavailable',\n                fallback: {\n                    tempe