⚡ Deploy moderno

Deploy es el acto de tomar tu proyecto y ponerlo en un servidor público, con una dirección a la que cualquiera puede acceder. Vercel es una plataforma que lo hace de forma casi automática.

El código en tu computadora solo lo ves tú. El deploy es lo que transforma el proyecto en algo real y compartible. Vercel hace que este paso sea simple y gratuito.

Vercel es ideal para sitios y apps modernos (React, Next.js, HTML). Observa tu repositorio y vuelve a hacer el deploy con cada cambio, sin comandos manuales.

El registro en Vercel con tu cuenta de GitHub y la autorización para que Vercel pueda ver tus repositorios.

Es el puente que conecta el lugar donde vive tu código (GitHub) con el lugar donde se publicará (Vercel). Sin esta conexión, no hay deploy automático.

Usa "Sign up with GitHub" para crear una cuenta ya conectada. Autoriza solo los repositorios que quieras publicar. El plan gratuito (Hobby) basta para empezar.

El paso para importar un repositorio en Vercel y hacer clic en «Deploy». En segundos, tu proyecto obtiene una dirección pública en funcionamiento.

Es el momento de estar "en línea" de la Ruta 2: ver tu sitio funcionando en un enlace real demuestra que el ciclo de deploy funciona de principio a fin.

Vercel detecta el tipo de proyecto por sí sola. Recibes una dirección projeto.vercel.app. A partir de ahí, cada git push vuelve a implementar.

Con cada branch o pull request, Vercel crea un deploy de "preview": una copia del sitio con su propia dirección, separada de la versión de producción.

Permite probar un cambio en un enlace real antes de modificar el sitio principal. Puedes mostrarle la novedad a alguien sin poner en riesgo la versión en línea.

La branch main se convierte en producción; las demás se convierten en previews. Cada preview tiene una URL única y desaparece cuando se elimina la branch.

El panel de configuración de Vercel: comando de build, carpeta raíz del proyecto, dominios y el botón para volver a ejecutar (redeploy) un deploy.

Los proyectos crecen y necesitan ajustes. Saber dónde hacerlos evita ese «funciona en mi PC, pero se rompe al desplegar».

En la mayoría de los casos, la configuración predeterminada ya sirve. Cambia "Root Directory" si el proyecto está en una subcarpeta. "Redeploy" repite el último deploy.

Cambiar la dirección predeterminada projeto.vercel.app por un dominio propio que compraste, como seusite.com.

Un dominio propio transmite profesionalismo y es más fácil de compartir. Vercel se encarga de HTTPS automáticamente y gratis.

Agrega el dominio en «Domains» y configura el DNS según indique Vercel. El certificado HTTPS (candado) se genera automáticamente.

Una base de datos es un lugar organizado para guardar información de forma permanente: usuarios, pedidos, mensajes. Piensa en una hoja de cálculo enorme y confiable que muchos programas pueden leer y escribir al mismo tiempo.

Casi todas las aplicaciones de verdad necesitan recordar algo entre una visita y otra. Sin una base de datos, todo se pierde cuando se cierra la página.

Los datos se almacenan en tablas (filas y columnas). Supabase usa PostgreSQL, una base de datos potente y gratuita, por debajo.

El paso para crear una cuenta, abrir un proyecto nuevo y dejar que Supabase aprovisione una base de datos PostgreSQL lista para usar.

Crear una base de datos desde cero solía ser complicado. Supabase te lo ofrece en unos pocos clics, sin que tengas que instalar nada.

Elige una región cerca de ti y guarda con cuidado la contraseña de la base de datos. El plan gratuito ya sirve para aprender y crear prototipos.

La organización de la base de datos: cada tabla guarda un tipo de cosa (p. ej., "usuarios"), las columnas son los campos (nombre, correo electrónico) y el tipo define qué cabe en cada columna (texto, número, fecha).

Una buena estructura evita el desorden y los errores. Definir las tablas y los tipos correctos desde el principio te ahorra muchos dolores de cabeza después.

Crea tablas con el "Table Editor" visual. Tipos comunes: text, int, bool, timestamp. Cada línea tiene un id único.

Las dos acciones más comunes en una base de datos: insertar (guardar una nueva fila) y consultar (buscar filas que cumplen un criterio). Es el "escribir y leer" de la base de datos.

Toda app funciona así: guarda lo que escribe el usuario y muestra de nuevo lo que ya se guardó. Sin insertar ni consultar, la base de datos queda inactiva.

Puedes insertarlo desde la pantalla o mediante código. El lenguaje que hay detrás es SQL (insert, select), pero Supabase también permite hacerlo todo de forma visual.

En cuanto creas una tabla, Supabase genera una API automáticamente: direcciones listas para que tu sitio lea y guarde datos en la base de datos por internet.

Normalmente, tendrías que programar un servidor entero para eso. Tener una API gratis conecta tu frontend con la base de datos en minutos.

Cada proyecto tiene una URL y una clave (anon key). La biblioteca supabase-js facilita las llamadas. Este es el gancho para el módulo de APIs.

El sistema listo de Supabase para registrar e iniciar sesión de usuarios: correo electrónico y contraseña, o iniciar sesión con Google y GitHub, sin que tengas que programarlo desde cero.

Iniciar sesión de forma segura es difícil de hacer bien. Usar una solución lista evita fallas graves y te permite enfocarte en el resto de la app.

Supabase administra contraseñas y sesiones. Con reglas de acceso (RLS), cada usuario solo ve sus propios datos. Activa los proveedores en la pestaña Authentication.

Una API es un conjunto de direcciones por las que un programa le pide información a otro. Piensa en un mesero: haces un pedido, lo lleva a la cocina y trae el plato; no necesitas saber cómo funciona la cocina.

Todo en la web moderna se comunica por API: el clima, los mapas, los pagos, tu banco en Supabase. Entender las API es entender cómo se conectan las apps.

Envías una solicitud a una URL y recibes una respuesta, casi siempre en formato JSON. La mayoría de las APIs web se comunican por HTTP.

Los cuatro verbos básicos de una API: GET lee, POST crea, PUT actualiza y DELETE borra. Cada uno describe la intención de la solicitud.

Usar el verbo correcto hace que la API sea predecible y esté organizada. Es el vocabulario estándar que entiende todo servicio web.

Recuerda el CRUD: Create=POST, Read=GET, Update=PUT, Delete=DELETE. GET nunca debe cambiar datos; POST e PUT envían un cuerpo con la información.

Dos formas de probar una API sin escribir una app: el curl hace la llamada desde la terminal; Thunder Client es una extensión de VS Code con una interfaz visual para eso.

Antes de conectar la API a tu sitio, es esencial comprobar si responde como esperas. Probar primero ahorra horas de depuración.

curl -X GET url hace la llamada más sencilla. Thunder Client guarda tus solicitudes y muestra la respuesta formateada. Revisa siempre el código de estado.

Usar el JavaScript de tu sitio para llamar a una API y mostrar el resultado en pantalla. La herramienta estándar del navegador para esto es el fetch.

Es lo que hace que un sitio esté "vivo": busca datos al instante y actualiza la página sin recargarla. Este es el corazón de cualquier app dinámica.

fetch(url) devuelve una promesa; usa await e .json() para leer la respuesta. Las llamadas son asíncronas: el código espera a que llegue la respuesta.

APIs abiertas que cualquiera puede usar para buscar datos listos: pronóstico del tiempo, dirección a partir del código postal (ViaCEP), cotización de monedas y mucho más.

Son la forma más fácil de practicar: ya recibes datos reales sin montar un servidor. Puedes enriquecer tu app con poco esfuerzo.

Algunas requieren una clave (API key) gratuita; otras, como ViaCEP, son abiertas. Lee la documentación para conocer la URL y el formato de la respuesta.

La práctica de prever que la API puede fallar (se cayó internet, el dato no existe, el servicio está fuera de línea) y mostrar un mensaje claro en vez de que la app se rompa.

En el mundo real, las solicitudes fallan. Una app que gestiona bien los errores parece profesional; una que se bloquea al primer fallo frustra al usuario.

Estado 200 y éxito; 404 no encontrado; 500 error del servidor. Usa try/catch y verifica response.ok antes de usar los datos.

Las variables de entorno son valores guardados fuera del código, como una clave de API o la contraseña de la base de datos. El programa las lee al ejecutarse, sin que estén escritas en el proyecto.

Permiten separar "cómo funciona la app" (código) de "con qué secretos funciona" (configuración). Cambiar un secreto no requiere modificar el código.

Son pares NOME=valor. El mismo código funciona de manera diferente en cada entorno (tu PC, producción) con solo cambiar las variables.

Un archivo llamado .env en la raíz del proyecto donde escribes tus variables, una por línea, para usarlas mientras desarrollas en tu computadora.

Es la forma estándar de guardar secretos durante el desarrollo, sin escribir la clave directamente en el código que va a GitHub.

Formato CHAVE=valor, sin espacios. El .env tiene que ir en el .gitignore (visto en la Ruta 1) para que nunca se suba.

El panel de Vercel donde registras las mismas variables de .env, pero para el sitio que está en línea. Como el .env no se sube; Vercel necesita recibir los secretos por aquí.

Sin esto, tu sitio publicado no puede acceder a la base de datos ni a las API. Es el paso que conecta el deploy con tus secretos de forma segura.

Agrégala en «Settings → Environment Variables». Puedes separarlas por entorno (Production, Preview). Después de cambiarla, vuelve a hacer el deploy.

GitHub Actions ejecuta tareas automáticas (pruebas, deploy) con cada push. Los «Secrets» son el lugar donde guardas claves para que esas tareas las usen de forma segura.

Las automatizaciones también necesitan secretos, pero nunca debes escribirlos en el archivo de configuración. Los Secrets resuelven esto.

Regístralo en «Settings → Secrets and variables → Actions». En el flujo, accedes a ellos mediante ${{ secrets.NOME }}. Aparecen enmascarados en los registros.

La regla de oro: las contraseñas, las claves de API, los tokens y el propio .env nunca deben subirse a GitHub. Una vez en el historial, se quedan allí para siempre.

Filtrar un secreto en un repositorio público es uno de los errores más comunes y peligrosos: los bots rastrean GitHub en busca de claves para usarlas de forma indebida.

Siempre define .env no .gitignore. Compruébalo con git status antes del commit. Si se filtró, considera que la clave está comprometida y cámbiala.

La rotación consiste en generar una clave nueva y descartar la anterior periódicamente o cuando hay sospechas de filtración. Es como cambiar la cerradura por seguridad.

Las claves antiguas que ya se han compartido son un riesgo. Rotarlas limita el daño: aunque una clave se filtre, pronto dejará de funcionar.

Genera la clave nueva en el servicio, actualízala en todos los lugares (.env, Vercel, Actions) y solo después revoca la anterior, para no romper la app a mitad del proceso.