2. 🕯️ La vela: publica el altar

Tu altar corre en tu laptop. Eso significa que existe mientras tu terminal esté abierta y nadie más lo puede ver. En este módulo pasa a tener dirección propia.

Fíjate en todo lo que está en gris: eso es lo que no tienes todavía, y es el módulo 3.

Conecta tu repo con Amplify Hosting

Amplify Hosting mira tu repo de GitHub y, cada vez que haces push, construye el sitio y lo publica. Tú no corres nada.

Ahora tarda unos minutos construyendo. No te quedes viendo la barra, que ese tiempo lo vamos a usar abajo.

Mientras construye: cdk bootstrap

CDK necesita un lugar en tu cuenta donde dejar los archivos del despliegue antes de crear nada. Ese paso se corre una sola vez por cuenta y Región, y se llama bootstrap. Lo corremos ahora para que en el módulo 3 no te cueste tiempo.

Igual en Windows, macOS y Linux:

npx cdk bootstrap --profile ofrenda

Si CDK muestra cambios de seguridad y pregunta si quieres desplegarlos, revisa que el stack sea CDKToolkit, escribe y y presiona Enter.

💰 Esto sí crea recursos

Bootstrap crea un stack llamado CDKToolkit con un bucket de S3, un repositorio de ECR y unos roles. Es el único paso del taller que crea cosas antes de que tengas app.

Ese stack no se borra con cdk destroy. Si quieres dejar la cuenta limpia al final, hay que borrarlo aparte, y está explicado en Qué se queda en tu cuenta.

Tu altar ya tiene dirección

Cuando Amplify termina, te da una URL que termina en amplifyapp.com. Ábrela.

Ahí está tu altar, con el set tradicional puesto, igual que en tu laptop.

npm run verify 2 https://main.xxxxx.amplifyapp.com

⚠️ Ya está en internet

Y esto ya es un hecho, no una advertencia: cualquiera con el link ve tu altar. Tenlo en cuenta en el módulo 4, que es donde subes tus fotos.

La lección del módulo: qué hace un build

Baja hasta el pie de tu página. Dice la fecha y hora en que se construyó.

git add web/src/componentes/layout/Encabezado.jsx
git commit -m "Mi ofrenda"
git push origin main

Nadie corrió nada en tu laptop. Hiciste push y tu código pasó por un build en la nube antes de llegar a quien visita tu altar. Esa es la diferencia entre subir archivos a un servidor y tener un pipeline.

Y aquí está la parte que vas a usar en el módulo 3

Tu altar va a necesitar saber la URL de tu API. Esa URL es distinta para cada quien y no tiene por qué estar en tu repo.

La variable se llama VITE_API_URL. Todavía no la configuraste y la versión actual de almacen.js tampoco la lee, así que el altar sigue guardando en el navegador.

En el módulo 3 el agente cambia almacen.js para usar esa variable. Después subes ese cambio a GitHub, agregas VITE_API_URL en Amplify y redespliegas sin necesitar otro commit para guardar la URL.

💡 Dos cosas sobre esa variable, por si luego construyes algo propio

El prefijo VITE_ no es decoración: Vite solo expone al navegador las variables que empiezan así. Usa VITE_API_URL únicamente para datos públicos, como la URL de esta API, y nunca para contraseñas, tokens ni llaves secretas.

Checkpoint