REST, GraphQL, WebSockets, SOAP, microservicios, serverless. No para usarlos hoy, sino para saber que existen, qué cuestan y cuándo preguntar por ellos.
Etiquetas
Para qué sirve esta clase
No vas a usar nada de esto la semana que viene. Y aun así es de las clases más importantes del semestre, por una razón muy concreta de la época en que vas a trabajar:
No puedes pedir lo que no sabes nombrar.
Si no sabes que existen los WebSockets, vas a resolver un chat con setInterval cada segundo — y la IA te va a escribir ese código encantada, sin advertirte nada, porque hace exactamente lo que le pediste. El límite de lo que una IA puede construir para ti es el límite de lo que tú puedes especificar. Esta clase amplía ese límite.
El objetivo no es que domines estas tecnologías. Es que sepas que existen, qué problema resuelven y qué cuestan, para que sepas cuándo preguntar por ellas.
Cómo hablan los sistemas
El primer snippet compara los cuatro estilos que te vas a encontrar. Dos comentarios que no caben ahí:
Sobre GraphQL: nació para resolver el over-fetching (traer 30 campos cuando usas 3) y el problema opuesto, tener que llamar a cinco rutas para pintar una pantalla. Es elegante, pero mueve la complejidad a otro lado: la caché de HTTP —que en REST te sale gratis— deja de funcionar igual. No es "REST pero mejor": es otro conjunto de compromisos.
Sobre SOAP: te lo menciono con honestidad. No es lo que elegirías para un proyecto nuevo hoy; es tecnología de los 2000, verbosa y basada en XML. Pero está muy vivo en banca, aseguradoras y sistemas de gobierno. Si en México te toca integrar con el SAT, con un banco o con un sistema empresarial heredado, vas a ver WSDL y sobres XML. Saber que existe y reconocerlo cuando aparezca es suficiente; nadie espera que lo domines desde ahora.
Tiempo real: la pregunta que decide
Todo el segundo snippet se reduce a una pregunta: ¿quién inicia la comunicación?
- Si siempre inicia el usuario → petición/respuesta. Ya sabes hacerlo.
- Si el servidor tiene algo que decir y el usuario no lo pidió → polling, SSE o WebSockets, en ese orden de complejidad.
El error más común en juniors (y en código generado por IA) es saltar directo a WebSockets porque suena profesional. Súbete de nivel solo cuando el anterior ya no alcance: WebSockets te obliga a manejar reconexiones, estado de conexión y un servidor que sostenga conexiones persistentes — cosas que el hosting estático y muchas funciones serverless simplemente no hacen.
Cómo se organiza un sistema
El tercer snippet insiste en algo que quiero que te lleves: monolito → microservicios no es una escalera evolutiva. No es que los sistemas "maduren" hacia microservicios; son compromisos distintos para problemas distintos.
Los microservicios resuelven un problema organizacional: permitir que muchos equipos desplieguen sin pisarse. Si eres un equipo de tres, no tienes ese problema — tienes el problema contrario, y los microservicios te lo empeoran. Un monolito bien organizado en capas es la respuesta correcta para la enorme mayoría de los proyectos, incluido el tuyo.
Y algo que suena a herejía en clase de arquitectura: casi todos los sistemas que funcionan bien son monolitos. Los que ves en las conferencias son la excepción, no la regla.
Qué cuesta correr lo que construyes
El cuarto snippet trae el caso real de esta misma plataforma: pasó de tres servicios (CMS + base de datos + frontend) a un solo contenedor, porque el contenido son archivos .md en el repositorio. Menos costo, cero mantenimiento de base de datos, y publicar es git push.
Esa es la lección que quiero que te lleves del semestre en materia de arquitectura:
La arquitectura más barata de operar es la que no tiene piezas. Cada servicio que agregas, alguien lo cuida a las 3 de la mañana. Cada base de datos hay que respaldarla. Cada secreto hay que rotarlo.
Agrega complejidad cuando el dolor lo justifique, no antes. "Podríamos necesitarlo algún día" es la frase que ha hundido más proyectos que cualquier bug.
Cómo seguir después de este curso
Terminas el semestre sabiendo construir y defender una aplicación completa. Los caminos naturales desde aquí:
- Hacia el backend — Node con Express, bases de datos, diseñar tus propias APIs. Es la continuación más directa de lo que viste hoy.
- Hacia el frontend profundo — TypeScript, testing, rendimiento, accesibilidad. Es donde se nota la diferencia entre alguien que arma pantallas y alguien que construye productos.
- Hacia DevOps — contenedores, CI/CD, infraestructura. Ya tocaste la punta con tu deploy.
Y un consejo final, que es el mismo con el que abrió el curso: la tecnología que aprendiste hoy va a cambiar. El criterio no. Saber leer código ajeno, detectar lo que está mal, preguntar qué problema estamos resolviendo realmente y decir "no" a la complejidad innecesaria — eso te va a servir en el lenguaje que sea, con la IA que sea, dentro de quince años.
Ejemplos de Código
4 ejemplos
Cómo hablan los sistemas entre sí
Cuatro estilos, y dónde te vas a topar con cada uno.
1REST (HTTP + JSON) ← el que ya usas
2 Simple, cacheable, universal. El estándar de facto de la web.
3 Problema típico: over-fetching (traes 30 campos y usas 3).
4 Lo verás en: prácticamente todo.
5
6GraphQL
7 Una sola ruta; el CLIENTE declara qué campos quiere.
8 Resuelve el over-fetching; complica caché y monitoreo.
9 Lo verás en: apps con muchas pantallas y datos anidados.
10
11gRPC (binario, HTTP/2)
12 Muy rápido y con contrato estricto. Difícil de depurar a mano.
13 Lo verás en: comunicación ENTRE servicios, no con el navegador.
14
15SOAP (XML + WSDL)
16 Anterior a REST. Verboso, con contrato formal muy estricto.
17 NO es lo que elegirías hoy, pero está VIVO en banca, aseguradoras
18 y sistemas de gobierno (SAT, IMSS). Si trabajas integrando
19 sistemas empresariales en México, te lo vas a encontrar.Tiempo real — cuatro niveles, de menos a más
La pregunta que decide es quién inicia la comunicación.
11. Petición/respuesta el usuario pide, el servidor responde
2 → 99% de los casos. Empieza SIEMPRE aquí.
3
42. Polling el cliente pregunta cada N segundos
5 → simple y suficiente si N ≥ 5s y hay pocos usuarios
6 → costo: peticiones que casi siempre responden "nada nuevo"
7
83. SSE (Server-Sent Events) el servidor EMPUJA, en un solo sentido
9 → HTTP normal, reconexión automática incluida
10 → ideal: notificaciones, tableros, progreso de una tarea
11
124. WebSockets canal abierto en AMBOS sentidos
13 → chat, colaboración en vivo, juegos, trading
14 → costo: conexión persistente, manejo de reconexión,
15 y un servidor que la sostenga (no todo hosting sirve)
16
17Regla: sube de nivel solo cuando el anterior ya no alcance.Cómo se organiza un sistema (no es una escalera)
No son etapas evolutivas; son compromisos distintos.
1MONOLITO
2 Todo en una aplicación. Simple de desarrollar, probar y desplegar.
3 ✅ Empieza aquí SIEMPRE. La mayoría de los sistemas mueren aquí, bien.
4 ❌ Con equipos grandes, todos se estorban al desplegar.
5
6MONOLITO EN CAPAS
7 Mismo despliegue, pero separado por dentro (presentación /
8 lógica / datos). ✅ Casi siempre la respuesta correcta.
9
10MICROSERVICIOS
11 Servicios independientes con su propia base de datos.
12 ✅ Resuelve un problema de EQUIPOS: desplegar sin coordinarse.
13 ❌ Red inestable, datos distribuidos, monitoreo complejo,
14 fallos parciales. Cuesta carísimo operarlos.
15
16SERVERLESS
17 Funciones que corren solo cuando se llaman; pagas por uso.
18 ✅ Excelente para cargas esporádicas o picos impredecibles.
19 ❌ Arranque en frío, límites de tiempo, y NO sostiene
20 conexiones persistentes (adiós WebSockets).Dónde vive tu código, y qué cuesta
El caso real de esta plataforma, con números.
1Hosting estático (Vercel, Netlify, Pages)
2 HTML/CSS/JS ya construidos, servidos desde un CDN.
3 Rapidísimo y suele ser gratis. No ejecuta código de servidor.
4
5PaaS (Railway, Render, Fly)
6 Le das el repo y ellos lo corren. Cómodo, más caro al escalar.
7
8VPS + contenedores (Docker, Dokploy, Coolify) ← esta plataforma
9 Tú administras el servidor. Máximo control, tú eres el de guardia.
10
11─── CASO REAL: la plataforma que estás leyendo ───
12
13ANTES: Strapi (CMS) + base de datos + frontend
14 3 servicios, backups, secretos que rotar, actualizaciones
15AHORA: un solo contenedor con el sitio; el contenido son
16 archivos .md en el repositorio
17RESULTADO: menos costo, cero mantenimiento de base de datos,
18 y publicar es "git push".
19
20La lección: la arquitectura más barata de operar es la que
21no tiene piezas. Cada servicio que agregas, alguien lo cuida.Recursos
3 recursos disponibles
Reto de Lectura
Reto de Decisión — Tres apps, tres arquitecturas
El ejercicio que separa a quien conoce nombres de quien sabe decidir. No hay código; hay criterio y costo de equivocarse.
Para cada uno de los tres proyectos, decide (a) el modelo de comunicación, (b) cómo se organiza el sistema y (c) dónde lo desplegarías. En cada caso justifica el costo de equivocarte.
Proyecto A — Chat de soporte de una tienda en línea Los clientes escriben y un agente responde. Se espera que los mensajes lleguen al instante y se vea "escribiendo…". Máximo 50 conversaciones simultáneas.
Proyecto B — Reporte mensual de ventas Un gerente entra una o dos veces al mes, elige un rango de fechas y descarga un PDF con las ventas. Los datos vienen de una base de 2 millones de registros y el reporte tarda ~40 segundos en generarse.
Proyecto C — Tablero de sensores de un invernadero 12 sensores reportan temperatura y humedad. La pantalla debe reflejar los cambios cada 5 segundos. La opera una sola persona desde una tablet.
Preguntas transversales:
- ¿En cuál de los tres usarías WebSockets y en cuál sería sobreingeniería? ¿Qué te cuesta equivocarte en cada dirección?
- El proyecto B tarda 40 segundos. ¿Qué problema tiene una petición HTTP normal ahí y cómo se resuelve sin WebSockets?
- ¿Alguno de los tres justifica microservicios? Defiende tu respuesta con un criterio, no con una preferencia.
- Un cliente te dice: "quiero que sea con microservicios y en la nube, como Netflix". ¿Qué le preguntas antes de aceptar?
Desafío de Código
Ejercicios — Ubica la pieza
Vocabulario mínimo para leer una oferta de trabajo sin perderte.
Explica en una o dos líneas, con tus palabras, qué es cada cosa y cuándo te la vas a encontrar:
- API REST
- GraphQL
- WebSocket
- SOAP
- Serverless
- CDN
- Balanceador de carga
- Cola de mensajes
Después: busca tres ofertas de trabajo reales de desarrollo web junior en tu ciudad y anota qué tecnologías de esta lista aparecen. ¿Cuáles se repiten?
Documentación Oficial
Documentación de apoyo
Para cuando te toque cada tema de verdad.