Late API: La API que se construye cuando la necesitas, no antes
*La mayoría de desarrolladores diseñan APIs asumiendo qué datos necesitarán sus clientes.* Luego pasan meses manteniendo endpoints muertos, versiones deprecadas, y cambios constantes porque los usuarios pedían algo diferente.
Late API es lo opuesto.
En lugar de predecir las necesidades de tus clientes, ejecutas tu aplicación, observas qué datos fluyen realmente, y construyes la API basada en eso. No es adivinanza. Es observación.
El patrón Late API no es nuevo — lo han usado Stripe, Twilio, y Supabase durante años — pero casi nadie lo documenta explícitamente. Aquí está cómo funciona y por qué reduce drásticamente el mantenimiento de APIs.
1. El Enfoque Tradicional: Predice Primero, Sufre Después
La mayoría de equipos siguen este flujo:
❌ El PM dice: "Necesitamos una API para usuarios y pedidos."
❌ Diseñas 40 endpoints "por si acaso".
❌ Los clientes usan 8 de ellos.
❌ Necesitan 2 más que no incluiste.
❌ Pasas 3 meses versionando endpoints viejos.
Este patrón existe porque es lo que enseña la mayoría de documentación sobre API design. REST principles, OpenAPI specs, "design for extensibility". Todo está pensado como si supieras qué necesitará el cliente en 2027.
No lo sabes.
2. Late API: Observa Primero, Diseña Después
Late API invierte el orden completamente:
✅ Ejecuta tu aplicación con datos internos.
✅ Observa qué consultas hacen realmente tus clientes.
✅ Extrae los patrones más comunes (80/20).
✅ Construye endpoints explícitamente para esos patrones.
✅ Versionas solo cuando el 60%+ de tus usuarios solicita cambios.
Para gestoriascercademi.com, por ejemplo, el sistema inicial era monolítico. Los clientes necesitaban:
- Buscar gestorias por localización.
- Ver reseñas de usuarios.
- Comparar precios típicos por servicio.
En lugar de construir una API genérica de "recursos gestorias", extrajo exactamente esos 3 casos de uso y construyó 3 endpoints. Nada más.
A los 6 meses, pedían un endpoint para "gestorias que hablan idiomas específicos". Lo agregó.
A los 12 meses, uno para "historial de precios por región". Lo agregó.
Cada endpoint se construyó porque el 70%+ de las consultas lo necesitaba. No porque pareciera "buena arquitectura".
3. Cómo Implementar Late API en Producción
Paso 1: Registra Todas las Consultas de Datos Internamente
Antes de exponer cualquier API pública, tu aplicación interna debe registrar:
- Qué datos se solicitan.
- Con qué frecuencia.
- Qué filtros se aplican.
- Qué campos se devuelven.
Here's a simple logging pattern in TypeScript:
Después de 1-3 meses, analizas los logs:
Paso 2: Extrae los Patrones 80/20
Tylerema, un SaaS de gestión fiscal que usaba Late API, encontró que el 87% de las consultas eran variaciones de solo 4 patrones:
- "Dame todos los clientes activos en esta región" (43% de consultas).
- "Dame todos los servicios con reseñas >4.5" (31%).
- "Dame precios típicos para este servicio en esta ciudad" (8%).
- "Dame gestorias que hablen este idioma" (5%).
Construyó exactamente esos 4 endpoints. Ninguno más.
Paso 3: Diseña Endpoints Específicos, No Genéricos
En lugar de:
Construyó:
Por qué? Porque ese endpoint específico puede pre-indexarse, cachearse más agresivamente, y el cliente sabe exactamente qué obtiene. No hay sorpresas.
Here's the actual endpoint:
Paso 4: Versiona Solo Cuando Cambian Tus Top 5 Patrones
La mayoría de APIs versinan por nerviosismo. "¿Y si alguien necesita otra cosa?"
Late API dice: versiona cuando el 60%+ de tus usuarios piden un cambio. No antes.
4. Casos de Uso Reales: Dónde Funciona Late API
Supabase usa Late API implícitamente. Construyeron la API REST después de ver cómo los usuarios consultaban su base de datos. No antes.
Resultado: 95.000+ usuarios, y casi cero cambios disruptivos en la API en 3 años.
Stripe hace lo mismo. El endpoint /v1/charges/create existe porque literalmente miles de integraciones lo usaban. Solo entonces lo documentaron como "official".
Twilio comenzó con 1 API. Ahora tiene 50. Cada una fue agregada después de que el 70%+ de los usuarios la pedía explícitamente.
5. Riesgos Reales y Cómo Mitigarlos
⚠️ "¿Y si necesito escalar sin redesignar la API?"
Late API no significa diseño pobre. Significa diseño basado en datos, no especulación.
Una vez que identificas tus top 5 patrones, todavía los diseñas bien: índices de base de datos, caching, rate limiting.
⚠️ "¿Qué pasa si mis usuarios usan la API diferente a lo previsto?"
Entonces lo ves en 4 semanas, no en 4 meses. Y ajustas. Ese es el punto.
6. Late API vs GraphQL: Cuándo Usar Cada Uno
❌ GraphQL como "solución genérica"
Muchos equipos usan GraphQL porque "los clientes pueden pedir los campos que necesiten". Luego descubren que mantener un resolver GraphQL para cada posible consulta es más trabajo que REST específico.
✅ Late API con REST
Identica tus top 5 patrones. Construye endpoints específicos. Hecho.
GraphQL tiene sentido si tienes >20 clientes diferentes con patrones de consulta completamente diferentes. Si tienes <5 clientes principales, Late API (REST) es 10x más simple.
Para gestoriascercademi.com: 3 clientes principales (web, iOS, partner dashboard). Late API fue obvio.
7. Métricas que Importan en Late API
- Query Coverage: ¿Qué porcentaje de consultas reales cubre tu API? (Target: >95%)
- Endpoint Usage: ¿Cuál es la distribución de uso entre endpoints? (Target: Top 3 covers >80%)
- Deprecation Impact: ¿Cuántos clientes se ven afectados si deprecas un endpoint? (Target: <10%)
- Cache Hit Rate: ¿Cuántas consultas se sirven desde cache? (Target: >70%)
La Realidad de Late API
No es revolución. Es pragmatismo.
Dejá de diseñar APIs para casos de uso que no existen. Ejecutá. Observá. Construí. Entonces escala.
Cada endpoint que construyas después de observar datos reales es un endpoint que necesitabas. No uno que crees que podrías necesitar.
Esos 3 endpoints específicos mantienen 10.000 usuarios. Los 40 endpoints genéricos que no usaba nadie eran ruido.
