Clase 4 - Martes, 01 de septiembre de 2026 (01 09 26) - Desarrollo e Implementación de sistemas en la nube
Guía de Estudio: Desarrollo e Implementación de Sistemas en la Nube - Arquitectura, APIs y Seguridad JWT
Este documento constituye un material de estudio integral basado en la formación técnica sobre arquitectura de sistemas distribuidos, el diseño de APIs y la implementación de mecanismos de seguridad mediante JSON Web Tokens (JWT).
1. Introducción General
El desarrollo moderno de sistemas en la nube se fundamenta en la distribución de responsabilidades a través de micro-APIs y arquitecturas desacopladas. A diferencia de las aplicaciones monolíticas tradicionales, los sistemas actuales dividen su lógica en servicios independientes (como gestión de usuarios, turnos o pagos) que se comunican entre sí mediante protocolos estándar como HTTP. Esta estructura permite que cada componente sea escalable, tecnológicamente independiente y fácil de mantener.
2. Marco Conceptual y Definiciones Clave
Para comprender el desarrollo en la nube, es fundamental dominar los siguientes conceptos:
- Frontend y Backend: El frontend representa la capa de presentación (ej. React) encargada de la interacción con el usuario. El backend (ej. Node.js/Express, Java) gestiona la lógica de negocio y el acceso a los datos.
- Hosting en la Nube: Plataformas donde se alojan las aplicaciones. Ejemplos mencionados incluyen Netlify (para frontend), Vercel (para APIs) y Supabase o MongoDB Atlas (para bases de datos).
- API REST (Representational State Transfer): Estilo de arquitectura para sistemas distribuidos que utiliza los verbos HTTP (GET, POST, etc.) para manipular recursos identificados por URLs.
- Middleware: Funciones que se ejecutan de manera intermedia en el ciclo de solicitud-respuesta de un servidor. Actúan como "capas de una cebolla" que envuelven la lógica principal para realizar tareas de pre-procesamiento (como seguridad) o post-procesamiento (como logs).
- Base64: Formato de codificación que transforma datos binarios o texto en una representación de caracteres ASCII. Es importante notar que no es cifrado, sino una forma de ofuscar u organizar la información.
3. Arquitectura y Documentación Técnica
La documentación de un sistema en la nube requiere precisión técnica para que los desarrolladores puedan implementar las comunicaciones correctamente.
3.1. Diagramas de Arquitectura
Un diagrama de arquitectura efectivo no solo debe listar las tecnologías (como React o Node.js), sino también indicar dónde está hosteado cada componente y cómo se comunican. Se recomienda el uso de iconos representativos para mejorar la claridad visual.
3.2. El Modelo Entidad-Relación (DER) en la Actualidad
Aunque el DER es útil para visualizar bases de datos, se considera en parte "antiguo" para el desarrollo de pequeñas APIs con responsabilidades divididas. En microservicios, las bases de datos suelen tener pocas tablas (4 o 5), lo que hace que el DER sea menos crítico que en los grandes monolitos de antaño.
3.3. Diagramas de Secuencia: Producto vs. Técnico
Existen dos niveles de diagramas de secuencia:
- De Producto: Muestra interacciones generales (ej. "El cliente solicita un turno").
- Técnicos: Detallan el verbo HTTP, la URL, los parámetros (Path variables, Query strings, Body JSON), los encabezados (Headers) y las respuestas (códigos de estado y estructura del JSON).
Elementos técnicos en la comunicación:
| Elemento | Descripción |
| Verbo HTTP | Define la acción (GET para obtener, POST para crear). |
| URL y Path Params | La dirección del recurso (ej. /api/gabinetes/:id). |
| Query Params | Parámetros después del signo ? (ej. ?estado=disponible). |
| Body (JSON) | Objeto de datos enviado en solicitudes POST o PUT. |
| HTTP Status Codes | Respuestas del servidor (200 OK, 400 Bad Request, 401 Unauthorized, 404 Not Found). |
4. Seguridad mediante JSON Web Token (JWT)
El JWT es el mecanismo más utilizado para manejar la autenticación (quién eres) y la autorización (qué puedes hacer) en entornos de nube. Es un token autocontenido y de alta performance.
4.1. Estructura de un JWT
Un token JWT se divide en tres partes separadas por puntos (.):
- Header (Encabezado): Indica el tipo de token y el algoritmo de encriptación (ej. HS256).
- Payload (Carga de datos): Contiene los "claims" o afirmaciones sobre el usuario. Datos comunes incluyen:
sub(Subject): El ID del usuario.exp(Expiration): Fecha y hora en que vence el token.role: El nivel de acceso (ej. admin, user).
- Signature (Firma): Es el resultado de combinar el Header y el Payload con una Clave Secreta que solo reside en el servidor. Esto garantiza que el token no haya sido alterado.
4.2. Funcionamiento del Mecanismo de Seguridad
El servidor no necesita consultar la base de datos en cada petición para saber quién es el usuario. Al recibir el token, el servidor aplica la clave secreta al Header y Payload recibidos; si el resultado coincide con la firma del token, la autenticidad está garantizada. Si alguien altera un solo carácter del Payload, la firma dejará de coincidir y el servidor rechazará la solicitud (Error 401).
5. Implementación de Middleware y Flujo de Autenticación
El uso de middlewares permite proteger rutas de manera modular.
5.1. El Modelo de Capas
Al proteger una ruta, se pueden encadenar múltiples middlewares:
- Capa 1: Authenticate Token: Verifica que el JWT sea válido y no haya expirado. Si es correcto, extrae la información del usuario y la inyecta en el objeto
request. - Capa 2: Is Admin: Verifica si el usuario inyectado en el
requesttiene el rol necesario. - Capa 3: Lógica de Negocio: La función final que accede a los datos solo si las capas anteriores permitieron el paso.
5.2. Códigos de Error Críticos
- 401 Unauthorized: El usuario no ha proporcionado un token válido o las credenciales de login son incorrectas.
- 403 Forbidden: El usuario está autenticado, pero no tiene permisos para acceder a ese recurso específico (ej. un cliente intentando acceder a rutas de administrador).
6. Ejemplos Prácticos y Casos Reales
Caso: Gestión de Turnos en una Estética
Para obtener la información de un gabinete y el profesional que lo atiende, el flujo técnico sería:
- Frontend: Envía
GET /api/gabinetes/10con el JWT en el HeaderAuthorization: Bearer <token>. - API Gabinetes:
- Verifica el token.
- Consulta la base de datos de gabinetes.
- Si el gabinete existe, llama internamente a la API de Profesionales para obtener quién atiende allí.
- API Profesionales: Devuelve el objeto del profesional a la API de Gabinetes.
- API Gabinetes: Une ambos datos y devuelve un JSON completo al Frontend con un código
200 OK.
7. Errores Comunes y Confusiones
- Confundir Autenticación con Autorización: Estar logueado (autenticado) no significa tener permiso para todo (autorizado). Por ello se usan los errores 401 y 403 de forma distinta.
- Almacenamiento del Token: Guardar el token en Cookies requiere permisos del usuario. Se suele preferir el
localStoragepara aplicaciones simples o memoria volátil para mayor seguridad. - Uso de Vistas en Base de Datos: Se desaconsejan por problemas de performance frente a las consultas directas u optimizadas.
- Exposición de la Clave Secreta: La clave secreta para firmar JWT debe estar en variables de entorno (
.env) y nunca subirse al repositorio de código.
8. Fechas Importantes y Avisos Académicos
Tras el análisis de la fuente, se identifican las siguientes indicaciones:
- Material de Estudio: El profesor ha habilitado una pestaña denominada "Material Extra" en el aula virtual. Esta contiene resúmenes detallados sobre:
- Modelo cliente-servidor.
- Estructura de URLs y puertos.
- Métodos HTTP y arquitectura REST.
- Formato JSON.
- Guía específica sobre JWT (explicación de partes y ejemplos).
- Entregas del Proyecto: Se menciona que la "Entrega 1" (Diagrama de Arquitectura) ha sido revisada para algunos grupos. Se espera que los diagramas de secuencia se iteren y perfeccionen técnicamente para las próximas clases.
- Próximas Sesiones: Se mantiene el horario habitual. Se enfatiza que los estudiantes deben traer dudas sobre la implementación de JWT y mostrar avances de código.
Nota: No se especificaron fechas exactas de exámenes parciales en la transcripción, pero se sugiere consultar periódicamente la pestaña de avisos del aula virtual.
9. Preguntas de Repaso
Nivel Básico
- ¿Cuál es la función principal de un Header en un JWT?
- ¿Qué diferencia hay entre un hosting para frontend (ej. Netlify) y uno para bases de datos (ej. Supabase)?
- Mencione tres verbos HTTP y su uso convencional.
Nivel Intermedio
- Explique el flujo de una solicitud que atraviesa un middleware de autenticación antes de llegar a la base de datos.
- ¿Por qué se dice que el JWT es "autocontenido"?
- ¿Qué sucede técnicamente cuando un servidor devuelve un error 403 en lugar de un 401?
Nivel Avanzado
- Describa el mecanismo de firma (Signature) y por qué previene la alteración de datos por parte de terceros.
- En una arquitectura de micro-APIs, ¿por qué es preferible que cada una tenga su propia base de datos o cuenta independiente?
- Diseñe la estructura de un endpoint
GET /api/mey explique cómo el backend identifica al usuario sin recibir un ID en la URL.