El Problema (Para el Recruiter)
Quería que mi portafolio se sintiera "vivo". Decidí añadir un "Widget de Actividad Reciente" que mostrara mi último proyecto de GitHub. Parecía simple: llamar a la API pública de GitHub y mostrar el resultado.
Lo programé y... ¡funcionó perfecto! Lo subí a mi web, orgullosa. Pero al día siguiente, o a veces después de refrescar la página 5 o 6 veces, el widget aparecía vacío o con un error. Un widget que falla es peor que no tener widget, da una imagen de poca fiabilidad.
El Dilema: ¿Por qué algo que funciona perfectamente en local falla de forma intermitente en producción? El clásico "en mi máquina sí funciona".
La Solución (Para el Desarrollador)
El problema no era mi código, sino mis *suposiciones*. Estaba usando la API de GitHub de forma anónima (sin una clave de API), lo cual está bien para pruebas, pero tiene un límite.
Abrí la pestaña "Network" en las herramientas de desarrollador y miré la respuesta de la API de GitHub. En las cabeceras (headers), encontré la respuesta:X-RateLimit-Remaining: 0
GitHub te da un límite de 60 peticiones por hora por dirección IP para peticiones no autenticadas. ¡Entre mis pruebas, las recargas de página y el build de la web, estaba agotando ese límite en minutos!
El dilema del hosting estático
La solución obvia es "usar una clave de API (autenticarse)", que te da 5.000 peticiones por hora. Pero, ¿dónde pones esa clave?
Estoy usando un hosting estático (GitHub Pages), lo que significa que todo mi código React se ejecuta en el navegador del cliente. Si pongo mi clave de API en ese código (en el useEffect), ¡cualquiera podría verla, robarla y usarla!
// ¡PELIGRO! NUNCA HACER ESTO EN EL FRONTEND
useEffect(() => {
fetch('https://api.github.com/users/SierraMa1/repos', {
headers: {
// ¡Mi clave secreta es visible para todo el mundo!
'Authorization': 'Bearer ghp_MI_CLAVE_SECRETA'
}
})
}, []);
La solución *real* para esto es migrar a un hosting que soporte backend (como Vercel o Netlify), donde mi *servidor* puede hacer la llamada con la clave secreta y "servir" los datos al frontend.
La Lección Aprendida
Una API no es solo "qué" datos te da, sino "cómo" te los da. Antes de integrar cualquier API, las primeras líneas de la documentación que hay que leer son las de "Autenticación" y "Límites de Tasa" (Rate Limiting).