Los problemas reales de la infraestructura de ecommerce
Barath Nadar pasó 4 años en la capa de infraestructura de Fynd, integrando cinco marketplaces y migrando servicios a gRPC. Cuando se fue, salió con una lista de problemas de infraestructura de ecommerce que nadie termina de resolver bien. El primero de todos: los contratos de API se desincronizan del código y nadie se entera hasta que algo explota en producción.
El API contract drift es la desincronización entre la implementación real de un endpoint y su especificación documentada (por ejemplo, un archivo OpenAPI). Pasa cuando alguien cambia la forma de una respuesta sin actualizar el contrato. En ecommerce, donde decenas de servicios internos y marketplaces externos consumen las mismas APIs, ese desfase rompe integraciones en producción semanas más tarde, cuando ya causó daño.
En 30 segundos
- Barath Nadar trabajó 4 años en la plomería de infraestructura de Fynd, no en features: migraciones gRPC, federación GraphQL e integración con Myntra, Amazon, Flipkart, Nykaa y Tata Cliq.
- El problema que más lo perseguía: los endpoints se alejan del spec OpenAPI durante el desarrollo y el error recién aparece tres semanas después, cuando un consumidor se rompe en prod.
- Su respuesta es api-watch, un proxy CLI local que se mete entre tu cliente HTTP y tu dev server, captura el tráfico y lo valida contra el spec.
- Cuando frenás el proxy, genera un reporte con cada endpoint llamado pero no documentado y cada respuesta que no coincide con el contrato.
- La idea de fondo: meter el feedback durante el desarrollo, no en code review ni en producción.
¿En qué trabaja realmente un ingeniero de infraestructura de ecommerce?
Nadar lo cuenta sin vueltas en su posteo en dev.to: su semana típica era responder preguntas sobre infra que él mismo había construido, trabajar en lo que cayera asignado, ayudar en decisiones de arquitectura y manejar 4 horas por día. Durante 4 años.
No tocaba features. Tocaba la capa de la que dependen el resto de los ingenieros para hacer su laburo. Si alguna vez te tocó mantener el código que usan otros veinte equipos, sabés que ahí no hay gloria: cuando funciona, nadie te ve; cuando se rompe, te ven todos.
El catálogo de tareas dice mucho sobre dónde están los problemas de infraestructura de ecommerce. Migraciones a gRPC (cambiar el protocolo de comunicación entre servicios sin que nada se caiga). Federación GraphQL (unificar varias APIs en un solo grafo consultable). Y la parte más áspera: integrar la plataforma con cinco marketplaces distintos, cada uno con su propio formato de respuesta, sus reglas y su manía. Complementá con automatizar despliegues con CI/CD.
¿Qué es el API contract drift y por qué rompe cosas en producción?
Ponele que armás un endpoint nuevo. Lo probás a mano, anda, lo mandás. Tres semanas después alguien nota que la forma de la respuesta no coincide con el spec OpenAPI. O peor todavía: un consumidor se cae en producción y recién ahí te enterás.
Esto, según Nadar, pasaba todo el tiempo. Y acá viene lo importante: no porque los ingenieros fueran descuidados. Pasaba porque no había ningún loop de feedback durante el desarrollo. Para cuando alguien detectaba el desfase, el daño ya estaba hecho.
El tema es que en ecommerce esto pega más fuerte que en una app cualquiera. Tu API no la consume un solo frontend. La consumen el carrito, el sistema de stock, el de pricing, el de envíos y cinco marketplaces externos que ni siquiera controlás. Un cambio chico en la forma de un campo (un string que pasó a ser null, un array que cambió de nombre) se propaga en silencio hasta que algo concreto deja de andar. Y para entonces ya no sabés cuál de los diez cambios de la semana lo provocó.
¿Cómo detectar el drift antes de que llegue a producción?
Acá entra api-watch, la herramienta open source que Nadar está construyendo. Es un proxy CLI local que se sienta entre tu cliente HTTP y tu dev server. Captura todo el tráfico que pasa mientras desarrollás, lo valida contra tu spec OpenAPI y, cuando frenás el proxy, te tira un reporte. Esto se conecta con lo que analizamos en elegir herramientas de integración continua.
¿Qué te da ese reporte? Dos cosas concretas según el autor:
- Cada endpoint que llamaste pero no está documentado en tu spec. O sea, lo que existe en el código pero nadie escribió en el contrato.
- Cada respuesta que no coincide con lo que el spec promete. El campo que cambió de tipo, el que desapareció, el que apareció de la nada.
La gracia es el momento. No es un test en CI que corre cuando ya pusheaste, ni una revisión que depende de que un humano se acuerde de mirar el spec. Es feedback mientras tenés el código fresco en la cabeza. Esa diferencia de timing es todo: arreglar un drift que detectás en el mismo rato cuesta minutos; arreglar uno que aparece tres semanas después cuesta una tarde de detective.
¿Cómo se compara con otras formas de cazar el drift?
No es que antes de api-watch no existiera nada. El problema es que cada enfoque tapa una parte del agujero y deja otra abierta. Esta es la comparación honesta entre las opciones más comunes:
| Enfoque | Cuándo detecta el drift | Esfuerzo | Dónde falla |
|---|---|---|---|
| Testing manual | Si te acordás de mirar el spec | Alto y dependiente de la persona | Se escapa apenas el equipo crece |
| Contract testing en CI | Después del push, en el pipeline | Setup inicial pesado | El feedback llega tarde, ya cambiaste de contexto |
| Validación en runtime (prod) | Cuando ya está en producción | Bajo de armar | El daño ya pasó, lo ves en los logs de error |
| Proxy local (api-watch) | Mientras desarrollás, en tu máquina | Correr un CLI y un spec OpenAPI | Necesitás tener el spec actualizado para que sirva |
Ninguno reemplaza del todo al otro. El proxy local ataca justo el hueco que dejan los demás: el rato entre que escribís el código y que lo mandás a revisión.
¿Por qué el testing manual no alcanza con marketplaces?
Probar a mano una integración con un marketplace es probar un día puntual, con los datos de ese día. Pero Amazon, Flipkart y Nykaa no te avisan cuando cambian la forma de una respuesta. Un campo opcional que un día viene vacío, una lista que a veces trae 0 items y a veces 500, un formato de fecha distinto según la región. Más contexto en expandir a múltiples mercados internacionales.
Multiplicá eso por cinco plataformas corriendo en paralelo y tenés la cuenta. Vos validaste el caso feliz, lo mandaste, anduvo. Tres semanas después un marketplace devolvió un edge case que tu código no contemplaba y la integración se cayó sin que nadie tocara nada de tu lado.
Por eso la apuesta de Nadar es validar contra el contrato de forma sistemática y temprana, no confiar en que una persona pruebe el caso correcto en el momento correcto. Si vas a desplegar este tipo de integraciones, conviene que la infraestructura donde corren (el hosting o el cloud) te dé entornos de staging estables para reproducir estos casos antes de prod.
Qué está confirmado y qué no
Confirmado (sale del propio posteo de Nadar):
- Trabajó 4 años en infraestructura en Fynd e integró Myntra, Amazon, Flipkart, Nykaa y Tata Cliq.
- api-watch es un proxy CLI local que captura tráfico HTTP, valida contra OpenAPI y genera un reporte al frenar.
- El reporte lista endpoints sin documentar y respuestas que no matchean el spec.
Lo que no queda claro todavía: el autor habla de “herramientas” en plural pero solo detalla api-watch en profundidad. No hay datos públicos de adopción, ni versión estable anunciada, ni benchmarks de performance del proxy. Tomalo como lo que es: un proyecto temprano de alguien que vivió el problema en serio, no una herramienta con años de batalla encima. Habría que ver cómo se banca con volúmenes altos de tráfico.
Errores comunes al manejar contratos de API
- Tratar el spec OpenAPI como documentación, no como fuente de verdad. Si el spec se escribe una vez y nadie lo vuelve a tocar, el drift es cuestión de tiempo. La corrección: que el contrato sea parte del flujo de desarrollo, validado en cada cambio.
- Confiar en que code review va a cachar el desfase. Un humano revisando un PR no compara campo por campo contra el spec. La corrección: automatizá la validación, no la dejes en manos de la atención de quien revisa.
- Probar solo el caso feliz en integraciones con marketplaces. El que rompe es siempre el edge case: el campo nulo, la lista vacía, el formato raro. La corrección: validá contra el contrato de forma sistemática, no contra el dato de hoy.
- Detectar el drift en producción y normalizarlo. Si tu único radar son los logs de error de prod, ya perdiste. La corrección: mové el feedback lo más cerca posible del momento en que escribís el código.
Preguntas Frecuentes
¿Qué es api-watch?
api-watch es una herramienta open source que funciona como proxy CLI local entre tu cliente HTTP y tu servidor de desarrollo. Captura todo el tráfico, lo valida contra tu especificación OpenAPI y genera un reporte cuando frenás el proxy. La está construyendo Barath Nadar, ex ingeniero de infraestructura de Fynd.
¿Qué es el API contract drift?
Es la desincronización entre la implementación real de un endpoint y su especificación documentada. Ocurre cuando un desarrollador modifica la forma de una respuesta sin actualizar el contrato OpenAPI. En sistemas de ecommerce con muchos consumidores, ese desfase rompe integraciones en producción semanas después del cambio original. Tema relacionado: ejecutar herramientas sin depender de APIs.
¿Por qué falla el testing manual en integraciones de ecommerce?
Porque prueba un caso puntual con datos de un momento dado, no el comportamiento del contrato en el tiempo. Los marketplaces como Amazon o Flipkart cambian formatos de respuesta sin avisar, y los edge cases (campos nulos, listas vacías, fechas con formato distinto) recién aparecen en producción.
¿Reemplaza api-watch al contract testing en CI?
No, lo complementa. El contract testing en CI valida después del push, dentro del pipeline. api-watch ataca el momento anterior: mientras desarrollás en tu máquina, antes de pushear. Cubren ventanas de tiempo distintas del mismo problema.
¿api-watch es gratis?
Nadar lo presenta como proyecto open source en su posteo de dev.to. Al cierre de esta nota no hay anuncio de versión estable, datos de adopción ni licencia detallada publicados, así que conviene seguir el repositorio del autor para los detalles concretos antes de adoptarlo en producción.
Conclusión
Lo valioso del posteo de Nadar no es la herramienta en sí, que todavía es temprana, sino el diagnóstico. El API contract drift no se arregla con más disciplina ni con más reviews: se arregla cerrando el loop de feedback durante el desarrollo, cuando todavía tenés el contexto fresco. Esa es la idea que vale, tengas api-watch o cualquier otra cosa.
Si manejás integraciones con marketplaces o APIs que consumen muchos servicios, la movida concreta es esta: tratá tu spec OpenAPI como fuente de verdad, automatizá la validación lo más temprano posible y dejá de confiar en que el caso feliz represente la realidad. El drift no se va a anunciar. Lo vas a ver cuando algo se rompa, y ahí ya es tarde.
