¿Qué estrategia seguirías para tipar una API HTTP o un SDK sin duplicar modelos por todas partes?

"¿Qué estrategia seguirías para tipar una API HTTP o un SDK sin duplicar modelos por todas partes?" toca un punto muy concreto de TypeScript: cómo tomar decisiones de arquitectura sin esconder el problema bajo una abstracción vistosa.

Una respuesta senior se nota cuando nombras qué riesgo quieres reducir con arquitectura en TypeScript para "Qué estrategia seguirías para tipar una API HTTP o un SDK sin duplicar modelos por todas partes", qué concesión aceptarías frente a api diseño y qué comprobarías antes de extender la decisión a todo el sistema.

Qué evalúa el entrevistador

• Si distingues qué parte de "Qué estrategia seguirías para tipar una API HTTP o un SDK sin duplicar modelos por todas partes" pertenece a arquitectura y cuál debería resolverse en api diseño.
• Si conviertes la respuesta en criterios observables: límites claros, impacto en el mantenimiento y forma de detectar regresiones.
• Si separas decisiones reversibles de irreversibles y justificas la arquitectura por velocidad de cambio, no por preferencia personal.

Respuesta sólida

• Empieza por el borde del problema: dominios, módulos o responsabilidades que hoy cambian a ritmos distintos en TypeScript.
• Justifica dónde pondrías las fronteras, qué acoplamientos aceptarías al principio y qué señal te haría revisar la decisión.
• Cierra con un criterio de validación real: coste de cambio, tiempo de entrega, número de puntos tocados o incidencias evitadas.

Compromisos y errores comunes

• Abrir más capas de las necesarias suele esconder la lógica importante y hacer más lenta la entrega sin resolver el acoplamiento real.
• Una arquitectura que nadie del equipo puede explicar en una pizarra rara vez aguanta bien el paso del tiempo.

Ejemplo de código

Un ejemplo pequeño ayuda a ver dónde colocarías la lógica de arquitectura en "Qué estrategia seguirías para tipar una API HTTP o un SDK sin duplicar modelos por todas partes" y qué parte dejarías derivada o encapsulada.

type LoadingState<T> =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; message: string };

function isSuccess<T>(state: LoadingState<T>): state is { status: "success"; data: T } {
  return state.status === "success";
}

const state: LoadingState<number> = { status: "success", data: 42 };
if (isSuccess(state)) console.log(state.data);

Lo importante no es la API concreta, sino que la solución hace visible la fuente de verdad, el tratamiento del error y el punto exacto donde arquitectura se sincroniza con api diseño dentro de "Qué estrategia seguirías para tipar una API HTTP o un SDK sin duplicar modelos por todas partes" en TypeScript.

Ejemplo o caso real

Un caso creíble para "¿Qué estrategia seguirías para tipar una API HTTP o un SDK sin duplicar modelos por todas partes?" aparece cuando una funcionalidad de TypeScript mezcla arquitectura con api diseño y el equipo empieza a tocar demasiados puntos para un cambio pequeño. Ahí conviene probar la solución sobre una pantalla o flujo acotado, medir si reduce fricción y solo después extender el patrón.

Frase corta de entrevista

Primero aclaro qué problema resuelvo con arquitectura y luego elijo la técnica; no al revés.