Dónde corren las cosas

Todo internet es pedido → respuesta

Cada vez que abrís una página web, tu browser (cliente) le pide datos a otra computadora (servidor) y recibe una respuesta. Cuando mandás un mail, cuando abrís Notion, cuando usás Claude — siempre el mismo modelo.

Este bloque es conceptual pero clave: entender cliente-servidor te da el criterio para decidir qué datos son seguros de enviar y cuáles no. Cada vez que le pasás un archivo a Claude, ese archivo viaja a los servidores de Anthropic. Sin este modelo mental, es magia; con él, es una decisión informada.

El vocabulario mínimo

Tres frases cortas que te van a servir todo el día

1. Si corre local, tus datos no salen. Un script de Python que procesa un CSV en tu Mac no manda nada a internet. Podés procesar info sensible sin preocuparte. Ojo con un matiz importante: si ese script local le pide algo a un LLM (Claude, GPT, etc.), el prompt y los datos que le pases al modelo sí viajan al servidor del proveedor. "Correr local" es sólo el código tuyo — la llamada al LLM es remota. La única forma de que tampoco eso salga es correr un modelo local en tu máquina con Ollama u otra herramienta similar (lo tenés como referencia al final).
2. Si corre remoto, pensá qué estás mandando. Cuando usás Claude, tu prompt y archivos viajan al servidor de Anthropic. No es bueno ni malo — es importante saberlo para decidir qué mandar.
3. Las API keys son contraseñas. Quien la tenga puede usar el servicio como si fuera vos. Nunca se comparten, nunca se suben a Git. En el próximo bloque vemos dónde guardarlas (.env).

Cómo un cliente entra a tu cuenta sin pedirte la contraseña

Las API keys son una forma de que un cliente (un script tuyo, una app) se autentique contra un servidor. Pero hay otra forma que usás todos los días sin darte cuenta: OAuth.

¿Te pasó alguna vez que entraste a una app nueva y te apareció una pantalla de Google que decía algo como "Esta app quiere acceder a tu email y a tu Drive — ¿Permitir?"? Eso es OAuth. Cada vez que hacés click en "Iniciar sesión con Google", "Conectar con GitHub", "Autorizar Slack", estás disparando un flow de OAuth.

El flujo, sin jerga

Acá vos sos dueño de una cuenta (ej. Google). Una app (cliente) — que puede ser Notion, un MCP, el CLI gog, lo que sea — quiere actuar en tu nombre. El servidor del proveedor (Google) es quien manda.

1. La app te redirige al sitio oficial del proveedor (accounts.google.com, github.com/login…). Nunca le das la contraseña a la app.
2. Te logueás en el sitio del proveedor (donde ya estás loguado casi siempre) y ves explícitamente qué permisos está pidiendo la app ("ver tu mail", "leer archivos de Drive"). Podés aceptar o rechazar.
3. Si aceptás, el proveedor le entrega a la app un token — una credencial limitada a esos permisos, que caduca sola y que vos podés revocar cuando quieras desde tu cuenta.
4. La app guarda ese token y lo usa para hacer pedidos a la API del proveedor en tu nombre (ej. leer tu Gmail, subir a Drive).

Dónde lo usás ya hoy

• "Iniciar sesión con Google / GitHub" en cualquier app (Notion, Figma, Vercel, Claude.ai…).
• gh auth login — cuando logueás el CLI de GitHub, se abre tu browser en github.com, autorizás, y el CLI guarda un token OAuth en tu Mac.
• gog — el CLI de Google Workspace que vas a ver usa OAuth para leer tu Gmail, Calendar y Drive en tu nombre, sin que el CLI sepa tu password de Google.
• Zapier, Make, n8n — cada "integración" nueva que conectás es un flow de OAuth contra ese servicio.
• MCP servers de servicios SaaS (Drive, Slack, Notion, HubSpot) — casi todos usan OAuth para conectarse a tu cuenta.

OAuth vs API key — cuándo se usa cada uno

Cuando en los bloques siguientes conectes MCPs a Slack, Drive o HubSpot, la primera vez vas a ver el flow: popup del proveedor, lista de permisos, "Autorizar". Si entendés qué está pasando ahí, sabés exactamente qué le estás dando a esa app — y cómo se lo quitás después.

El modelo cliente-servidor, en 10 min

Si hay un solo video del pre-work que ver para este bloque, que sea éste.

Ver cliente-servidor en vivo con curl

El comando curl es un cliente HTTP — le pide datos a un servidor y te imprime la respuesta. Es la forma más directa de ver el modelo en acción.

curl https://api.github.com                # meta-info de la API de GitHub
curl https://api.github.com/users/torvalds # datos del perfil de Linus Torvalds
curl https://wttr.in/Buenos+Aires          # el tiempo, en ASCII art
curl https://httpbin.org/ip                # te devuelve tu IP pública

Cada uno de esos comandos es tu Mac (cliente) pidiéndole a un servidor remoto. Los datos van y vienen por internet. El servidor responde con JSON o texto plano.

Combinando con jq para leer el JSON

Si instalaste jq en el bloque anterior (o corrés brew install jq ahora), podés formatear la respuesta:

curl -s https://api.github.com/users/torvalds | jq .
curl -s https://api.github.com/users/torvalds | jq .public_repos
curl -s https://api.github.com/users/torvalds | jq '.name, .bio'

El -s es "silent" (suprime la barra de progreso). El | (pipe) pasa la salida de curl como entrada de jq. Esto ya es programación — estás componiendo dos programas.

Para los que van rápido

• Armá tu propio localhost: corré python3 -m http.server 9999 en una carpeta con archivos. Abrí http://localhost:9999 en el browser. Tu Mac ahora es cliente y servidor.
• Probá APIs de datos públicos: PokéAPI, Rick and Morty, Chuck Norris.
• Mirá los headers de la respuesta con curl -I https://growketing.com. Eso es metadata del servidor — versión, tipo de contenido, cache.
• Leé sobre HTTP status codes: 200 (OK), 404 (no encontrado), 500 (servidor explotó). Los vas a ver seguido.

¿Lo hiciste y lo entendés?

Bloque corto pero conceptualmente denso. Si las 3 reglas no te cierran, preguntale a Gonza antes de pasar al siguiente — son la base para entender seguridad el resto del día.

Videos y lecturas