Desplegar un proyecto con API key en GitHub Pages te enfrenta a un dilema real: tu portafolio necesita una URL pública, pero tu API key viaja en el frontend y queda expuesta. Aquí verás cómo publicar archivos estáticos paso a paso, qué riesgos asumes y qué alternativas existen para blindar tu aplicación.

¿Por qué exponer la API key en el frontend es inevitable con archivos estáticos?

Todo lo que vive en el navegador es público. Si tu API key está en un archivo JavaScript, cualquiera puede abrir el inspector de elementos y leerla en segundos.

En el flujo del curso, la API key se guardaba en secrets.js y ese archivo estaba listado en el .gitignore para no subirla al repositorio de GitHub. Esa protección funciona mientras corres el proyecto en local, pero se rompe en el momento en que necesitas hacer deploy en GitHub Pages, porque el archivo debe viajar con el resto del código estático.

¿Se puede proteger una API key solo con frontend? No. Cualquier valor que el navegador necesite para hacer la petición es visible desde el inspector. La única forma real de ocultarla es moverla a un backend propio.

¿Qué alternativas existen para proteger tu API key en producción?

La diferencia clave está en quién hace la petición a la API externa. Si la hace el navegador, la key es pública; si la hace un servidor que tú controlas, queda guardada del lado seguro.

• GitHub Pages: solo sirve archivos estáticos HTML, CSS, JavaScript e imágenes. No puedes controlar el backend, así que la API key queda expuesta [04:00].
• Heroku, Vercel, AWS, DigitalOcean, Google Cloud, Azure: te permiten desplegar tu propio backend en Node.js, Python, Go o PHP. Ese backend guarda la API key y hace las peticiones de forma privada [04:30].
• Variables de entorno: en plataformas como Heroku, agregas la API key como variable de ambiente. Tu código la llama por nombre, nunca aparece en el repositorio [16:00].

Si todavía no dominas backend, GitHub Pages es válido como primer despliegue. Si quieres llevar el proyecto a una empresa o producto real, vale la pena aprender los fundamentos de Node.js o el lenguaje que prefieras.

¿Cómo hacer deploy paso a paso en GitHub Pages?

El truco es no tocar la rama principal. Vas a crear una rama dedicada al deploy donde sí incluirás el secrets.js, mientras main sigue limpia.

Crear una rama dedicada al deploy

Desde la terminal, parado en la carpeta del proyecto, ejecuta:

bash git checkout -b githubpages

Esto crea y te mueve a una nueva rama llamada githubpages. Aquí harás los cambios que no quieres mezclar con tu rama principal [08:00].

Quitar secrets.js del gitignore y commitear

Abre tu archivo .gitignore y elimina la línea que ignora src/secrets.js. Luego:

bash git add .gitignore git add . git commit -m "El commit más doloroso del mundo: deploy" git push origin githubpages

Con esto subes la rama githubpages con la API key incluida. Tu rama main sigue intacta, sin exponer credenciales [09:30].

Activar GitHub Pages desde Settings

En GitHub, entra a tu repositorio, ve a Settings y busca la sección Pages. Selecciona la rama githubpages y la carpeta root como fuente. No elijas tema en Choose a theme, porque eso usaría tu README en vez de tu index.html [11:00].

Guarda los cambios y espera entre 30 segundos y unos minutos. La URL final tiene el formato usuario.github.io/nombre-repositorio.

¿Por qué seleccionar root y no docs? Porque tu index.html está en la raíz del repositorio. Si lo tuvieras dentro de una carpeta /docs, elegirías esa opción.

¿Cómo monitorear el uso de tu API key en TheMovieDB?

Una vez desplegado, TheMovieDB te ofrece un panel de control para vigilar tu API key en themoviedb.org/settings/api. Ahí encuentras cuatro pestañas útiles.

• Details: registra el nombre y la URL de tu aplicación desplegada.
• Directory: lista las aplicaciones aprobadas que pueden usar tu key.
• Sessions: muestra usuarios que entraron si trabajas con user-based authentication.
• Stats: gráfica el número de solicitudes por día, los picos de uso y filtra por unique users para detectar si alguien más está usando tu key sin permiso [17:00].

Este monitoreo no impide el robo, pero sí te avisa cuándo ocurre algo raro y te permite regenerar la key a tiempo.

¿Qué validar después del deploy en tu aplicación?

Abre la URL pública en el navegador y prueba todos los flujos: tendencias, categorías, like a películas favoritas, lazy loading al hacer scroll. En la pestaña Network de DevTools, activa el throttling en Slow 3G y recarga limpiando caché para confirmar que los loading skeletons aparecen correctamente.

Un detalle a pulir: cuando la lista de favoritas queda vacía, aparece un espacio en blanco sin mensaje. Lo ideal es mostrar un texto distinto según el estado, cargando, error o lista vacía. Queda como reto.

Cuéntame en los comentarios la URL donde desplegaste tu aplicación y si decidiste protegerla con tu propio backend o asumiste el riesgo del deploy estático.