TypeScript el escudo

En 2024, el equipo de TypeScript de Microsoft publicó un dato que circuló ampliamente en la comunidad: el tipado estático previene aproximadamente el 15% de todos los bugs que llegan a producción. Para una aplicación bancaria que procesa miles de transacciones diarias, ese 15% no es un número de blog es la diferencia entre un incidente de compliance y un mes sin incidentes.

Por qué JavaScript solo no es suficiente a escala

JavaScript es dinámico por diseño. Una función puede recibir un string, un número o undefined y el código compila sin quejarse. Los errores aparecen en runtime, en producción, cuando el usuario ya está afectado.

En proyectos pequeños, eso es manejable. En un sistema con 50,000 líneas de código, 5 desarrolladores trabajando en paralelo y módulos que se llaman entre sí a través de 3 capas de la arquitectura, un campo que cambió de nombre en el backend puede silenciosamente romper 8 pantallas del frontend sin que nadie lo note hasta que el cliente llama.

TypeScript estricto como práctica de producción

En Ab4cus usamos TypeScript con strict: true en todas las capas: frontend Next.js, mobile Expo, backend NestJS. Eso significa:

• noImplicitAny: ninguna variable puede tener tipo implícito any
• strictNullChecks: null y undefined se manejan explícitamente — sin "cannot read property of undefined" en producción
• strictFunctionTypes: los callbacks y funciones se validan en ambas direcciones

Zod + tRPC: type safety de extremo a extremo

TypeScript solo garantiza la consistencia dentro de un proyecto. El problema real en aplicaciones modernas es la frontera entre frontend y backend: el cliente hace una llamada a una API y asume que los datos van a tener cierta forma pero si el backend cambia, esa asunción se rompe en runtime.

En Ab4cus resolvemos esto con dos herramientas:

Zod define los schemas de validación que funcionan tanto como tipos TypeScript (en tiempo de compilación) como validadores de datos (en tiempo de ejecución). Un schema KYC definido en Zod valida los datos antes de que lleguen a la base de datos Y provee los tipos TypeScript para que el frontend sepa exactamente qué campos tiene:

const kycSchema = z.object({
  fullName: z.string().min(2),
  idNumber: z.string().regex(/^[A-Z0-9-]+$/),
  pepStatus: z.boolean(),
  sanctionScreening: z.boolean(),
});

type KYCFormData = z.infer<typeof kycSchema>;
// El tipo TypeScript se genera automáticamente del schema

tRPC conecta el backend con el frontend sin necesidad de un contrato OpenAPI separado. Cuando el equipo de backend modifica un endpoint cambia el nombre de un campo, agrega un parámetro obligatorio, modifica el tipo de retorno el error aparece instantáneamente en el IDE del desarrollador frontend. No en producción. No en QA. En el IDE, antes de que el cambio se commitee.

El impacto real en proyectos fintech

En un sistema de transferencias bancarias, el monto de una transacción puede representarse como number, string, Decimal o BigInt y las conversiones incorrectas entre estos tipos generan errores de precisión financiera. TypeScript estricto con tipos explícitos en cada capa hace que esos errores sean imposibles de compilar, no solo difíciles de introducir.

Para nuestros clientes, el beneficio es concreto: menos bugs en producción, menor costo de mantenimiento, y la capacidad de onboardear nuevos desarrolladores en semanas en lugar de meses porque el código se autodocumenta a través de sus tipos.

→ Construir tu proyecto con TypeScript estricto desde el día uno