Proyecto Final: Construye un Feature End-to-End con IA

Todo Se Junta Aquí

🔄 Repaso rápido: En la lección anterior, exploramos decisiones de arquitectura y diseño de sistemas. Ahora construyamos sobre todo lo aprendido en las siete lecciones anteriores.

A lo largo de este curso aprendiste a usar IA para generación de código, debugging, testing, revisión de código, documentación y decisiones de arquitectura. Ahora es momento de usar todo junto en un solo feature, desde canvas en blanco hasta código listo para producción.

Esto no es un ejercicio de juguete. Vamos a construir un feature que una aplicación real podría necesitar, y usaremos IA en cada etapa del proceso. Vas a ver cómo las técnicas se componen — cada etapa es más rápida y efectiva gracias a las etapas asistidas por IA que vinieron antes.

El Feature: API de Rate Limiting

Vamos a construir un sistema de rate limiting para una API. Aquí va por qué es un capstone excelente:

• Involucra decisiones de arquitectura (dónde guardar contadores, qué algoritmo)
• Necesita implementación cuidadosa (condiciones de carrera, edge cases)
• El testing es crítico (timing, concurrencia, condiciones de frontera)
• Necesita documentación clara (otros developers van a configurarlo)
• Las implicaciones de seguridad requieren revisión cuidadosa

Requerimientos:

• Limitar requests de API por usuario por ventana de tiempo
• Soportar diferentes límites para diferentes endpoints
• Retornar headers estándar de rate limit (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset)
• Manejar edge cases (clock skew, servidores distribuidos, tráfico burst)
• Configurable como middleware (fácil de agregar a cualquier ruta)

Etapa 1: Decisión de Arquitectura (Lección 7)

Primero, decidimos cómo construirlo. El prompt:

Necesito agregar rate limiting a nuestra API Express.js/
TypeScript. Ya usamos Redis para caching.

Compara estos enfoques de rate limiting para nuestra
situación:
1. Fixed window counter
2. Sliding window log
3. Sliding window counter
4. Token bucket

Restricciones:
- ~10,000 usuarios activos
- Necesitamos límites por-usuario, por-endpoint
- 3 instancias de API detrás de un load balancer
- Redis disponible (ya en nuestro stack)
- Debe manejar 1,000 req/sec en pico

Para cada enfoque, analiza: precisión, uso de memoria en
Redis, complejidad de implementación y comportamiento en
las fronteras de ventana.

La IA expone los trade-offs. Para nuestro caso, recomienda el enfoque de sliding window counter — es suficientemente preciso (sin spikes de frontera como fixed window), eficiente en memoria (a diferencia de sliding window log), y más simple que token bucket.

Tu decisión: Sliding window counter con Redis. Lo documentas como ADR.

Etapa 2: Generación de Código (Lección 2)

Ahora genera la implementación. Nota cómo proporcionamos el contexto de nuestro codebase:

Implementa un middleware de rate limiting para Express.js
con TypeScript.

Algoritmo: Sliding window counter usando Redis
Storage: Nuestra instancia Redis existente (ioredis)

Nuestro patrón de middleware:
[pega un middleware existente como ejemplo]

Requerimientos:
- Acepta config: { windowMs: number, maxRequests: number }
- Formato de key: ratelimit:{userId}:{endpoint}:{windowId}
- Retorna 429 con header Retry-After cuando excede límite
- Agrega headers X-RateLimit-* a todas las respuestas
- Maneja fallas de conexión a Redis (fail open)
- TypeScript con tipos estrictos

Genera:
1. La interface RateLimitConfig
2. La función factory del middleware
3. Las operaciones Redis (increment, check, cleanup)

La IA genera el middleware. El core se ve más o menos así:

interface RateLimitConfig {
  windowMs: number;
  maxRequests: number;
  keyPrefix?: string;
  failOpen?: boolean;
}

const createRateLimiter = (config: RateLimitConfig) => {
  return async (req: Request, res: Response, next: NextFunction) => {
    const userId = req.user?.id ?? req.ip;
    const endpoint = req.route?.path ?? req.path;
    const windowId = Math.floor(Date.now() / config.windowMs);
    const prevWindowId = windowId - 1;

    // Sliding window calculation
    const currentKey = `ratelimit:${userId}:${endpoint}:${windowId}`;
    const prevKey = `ratelimit:${userId}:${endpoint}:${prevWindowId}`;

    try {
      const [currentCount, prevCount] = await Promise.all([
        redis.incr(currentKey),
        redis.get(prevKey),
      ]);

      if (currentCount === 1) {
        await redis.expire(currentKey, Math.ceil(config.windowMs / 1000) * 2);
      }

      const elapsed = (Date.now() % config.windowMs) / config.windowMs;
      const weight = (Number(prevCount) || 0) * (1 - elapsed) + currentCount;
      const remaining = Math.max(0, config.maxRequests - Math.ceil(weight));

      res.set({
        'X-RateLimit-Limit': String(config.maxRequests),
        'X-RateLimit-Remaining': String(remaining),
        'X-RateLimit-Reset': String(Math.ceil(((windowId + 1) * config.windowMs) / 1000)),
      });

      if (remaining <= 0) {
        return res.status(429).json({ error: 'Too many requests' });
      }
      next();
    } catch (error) {
      config.failOpen !== false ? next() : res.status(503).json({ error: 'Service unavailable' });
    }
  };
};

Etapa 3: Debugging (Lección 3)

Lo corres localmente y notas algo raro: el conteo de rate limit está ligeramente off cuando llegan múltiples requests simultáneamente. Hora de debuggear:

Veo una condición de carrera en mi rate limiter. Cuando
llegan 10 requests concurrentes, el contador a veces
muestra 8 o 9 en vez de 10.

El issue: redis.incr() y redis.get() son comandos
separados. Entre el INCR y el GET, otro request podría
modificar el contador.

¿Cómo corrijo esta condición de carrera?

La IA sugiere usar un script Lua de Redis para hacer la operación increment-and-check atómica:

local current = redis.call('INCR', KEYS[1])
if current == 1 then
  redis.call('EXPIRE', KEYS[1], ARGV[1])
end
local prev = redis.call('GET', KEYS[2]) or 0
return {current, prev}

✅ Revisión Rápida: ¿Por qué un script Lua de Redis resuelve la condición de carrera que no se resuelve con comandos individuales?

Esto corre atómicamente en el servidor Redis — imposible que haya condición de carrera.

Etapa 4: Testing (Lección 4)

Ahora genera tests para el rate limiter:

Escribe tests comprehensivos para este middleware de
rate limiting usando Jest y Supertest.

Categorías de tests:
1. Rate limiting básico (requests dentro del límite pasan,
   sobre el límite retorna 429)
2. Comportamiento de sliding window (requests de la
   ventana anterior afectan la actual)
3. Correctitud de headers (valores correctos de
   X-RateLimit-*)
4. Manejo de falla Redis (comportamiento fail open)
5. Aislamiento por usuario (requests de A no afectan a B)
6. Aislamiento por endpoint (/api/users no cuenta contra
   /api/posts)
7. Reset de ventana (límite se resetea después de la
   ventana)
8. Manejo de requests concurrentes

La IA genera tests cubriendo todos estos escenarios. Presta atención especial a los tests de requests concurrentes y fronteras de ventana — estos son los edge cases que rompen rate limiters en producción.

Etapa 5: Revisión de Código (Lección 5)

Antes de mergear, pasa el código por revisión con IA:

Revisa este middleware de rate limiting para producción.

Enfócate en:
1. Seguridad: ¿Pueden los usuarios bypassear el rate limit?
2. Rendimiento: ¿Cuellos de botella bajo carga?
3. Confiabilidad: ¿Qué pasa cuando las cosas fallan?
4. Correctitud: ¿La matemática de sliding window está bien?

La IA podría flaggear:

• “Los usuarios podrían bypassear el rate limiting spoofing el header X-Forwarded-For si caes al req.ip. Asegúrate de que tu proxy esté configurado para sobrescribir, no appendear.”
• “El script Lua debería manejar el caso donde KEYS[2] expiró. redis.call('GET') retorna false, no 0 — haz el cast explícitamente.”
• “Considera agregar una función skip al config para que health check endpoints puedan bypassear el rate limiting.”

Cada flag previene un potencial issue de producción.

Etapa 6: Documentación (Lección 6)

Finalmente, documenta el feature:

Genera documentación para nuestro middleware de rate
limiting. Audiencia: developers de nuestro equipo que
necesitan agregar rate limiting a sus endpoints.

Incluye:
1. Quick start (cómo agregar rate limiting a una ruta)
2. Opciones de configuración con defaults
3. Cómo funciona el algoritmo de sliding window (breve)
4. Headers de respuesta explicados
5. Respuestas de error
6. Configuraciones comunes (estricta para auth, relajada
   para reads)
7. Guía de troubleshooting

La IA produce documentación que permite a cualquier miembro del equipo agregar rate limiting a sus endpoints en minutos, sin necesitar entender los internals del sliding window.

El Flujo Completo en Números

Total sin IA: 12-20 horas a lo largo de varios días Total con IA: 2-3 horas en una sola sesión

Eso no es 10x cortando esquinas. Cada etapa es exhaustiva — probablemente más exhaustiva que la versión sin IA, porque la IA detecta edge cases e issues de seguridad que los humanos se saltan bajo presión de tiempo.

Tu Reto

Construye un feature de tu propio proyecto usando este flujo completo:

1. Elige un feature que involucre decisiones reales (no solo CRUD)
2. Arquitectura: Usa IA para explorar opciones y documenta tu decisión
3. Genera: Escribe código con IA usando el contexto de tu codebase
4. Debuggea: Cuando surjan issues, usa la trifecta de debugging
5. Testea: Genera tests comprehensivos incluyendo edge cases
6. Revisa: Corre una revisión de código con IA enfocada en seguridad y rendimiento
7. Documenta: Crea documentación para developers desde el código final

Mide tu tiempo. Compara con lo que normalmente tomaría. La diferencia es tu multiplicador de desarrollo con IA.

Lo que Aprendiste en Este Curso

Conclusiones Clave

• El flujo asistido por IA toca cada etapa del desarrollo, no solo escribir código
• Cada etapa amplifica la siguiente — buenas decisiones de arquitectura facilitan la generación, buenos tests aceleran la revisión
• La IA reduce un feature de varios días a unas pocas horas enfocadas
• Tú eres dueño de las decisiones, la IA acelera la ejecución
• Los mejores resultados vienen de combinar tu juicio con la exhaustividad de la IA
• Empieza a usar estas técnicas en trabajo real — la curva de aprendizaje es corta y el retorno es inmediato

Felicidades por completar Programa Más Rápido con IA. Ahora ve y construye algo increíble — deja que la IA se encargue de las partes que antes te frenaban.