TypeScript + Python: un ingeniero, dos ecosistemas y un contrato

Cada vez más productos en los que trabajo tienen dos partes. Una es lo que la gente usa: una interfaz Next.js, una API Node.js, autenticación y pagos. La otra se ocupa de los modelos: inferencia, embeddings, audio y procesamiento de datos. La primera habla TypeScript; la segunda, Python. Dominar ambos no consiste en coleccionar lenguajes, sino en hacerse responsable de la unión entre ellos, justo donde fallan muchos productos de IA.

La buena noticia es que ambos ecosistemas se parecen más de lo que parece. Zod tiene su equivalente en Pydantic; tsc, en mypy y pyright; ESLint y Prettier, en Ruff; npm y pnpm, en uv y Poetry. FastAPI cumple un papel parecido a Express y NestJS, y además genera OpenAPI a partir de modelos tipados. Aplico la misma disciplina en ambos lados: tipos estrictos, un formateador indiscutible, dependencias fijadas y pruebas en CI.

El contrato entre ambos es el archivo más importante del sistema. Lo defino una vez y genero el resto: los modelos Pydantic de FastAPI producen un esquema OpenAPI, del que se generan el cliente TypeScript y sus tipos. Renombra un campo en Python y falla la compilación de Next.js antes de que un usuario vea un undefined. Para el trabajo asíncrono, el contrato es un payload de tarea con un esquema en ambos extremos, no un bloque de JSON libre que cada parte interpreta a su manera.

La división de responsabilidades es estricta. TypeScript se ocupa de la identidad, los permisos, el dinero y la UI. Python se ocupa del modelo y nada más: recibe una tarea, realiza el trabajo pesado —una voz con StyleTTS2, un lote de embeddings o el análisis de un documento— y devuelve el resultado. El servicio Python no habla con el navegador ni decide quién tiene permiso para hacer qué. Las llamadas rápidas usan HTTP; las lentas, una cola, con timeouts, reintentos e idempotencia en ambos lados.

Las diferencias también importan y respetarlas forma parte del trabajo. Python permite prototipar en notebooks, pero un notebook no es producción: el código funcional pasa a un módulo con pruebas. La concurrencia de Python no es el event loop de Node: la inferencia intensiva en CPU corresponde a procesos worker o a un servicio GPU, no a un manejador de peticiones async. También cambian las unidades de despliegue —una imagen ligera de Node frente a una imagen Python con CUDA y los pesos del modelo— y, por tanto, su escalado, caché y coste.

Para el cliente, el valor de contar con un ingeniero en ambos lados es sencillo: no hay una capa de traducción entre «la persona de IA» y «la persona web», ni una API de la que ambos se culpen. Si tienes un modelo que funciona en un notebook y una aplicación web que aún no sabe utilizarlo, envíame ambos. Te propondré el contrato que pondría entre ellos y la primera versión que lanzaría.