Arquitectura de la plataforma
Proyecto de grado del SENA · Actualizado el 13 de octubre de 2026
Esta página explica cómo está construida la plataforma MetCommerce, tomando como referencia la tienda demo Tennix Shop, que está en producción. Es para quien quiera revisar el detalle técnico; si buscas qué incluye cada plan, está en la página principal.
1. Componentes
- Tienda (tennix-shop.com): sitio estático en HTML, CSS y JavaScript, sin frameworks ni paso de compilación.
- Panel de administración (admin.tennix-shop.com): también estático; todo lo que muestra lo pide a la API.
- API REST (api.tennix-shop.com): Node.js con Express. Agrupa las rutas en autenticación, dashboard, categorías, productos, pedidos, inventario, pagos, backups y vistas previas para redes sociales.
- Base de datos: MySQL.
- Servicios externos: Mercado Pago (pagos) y Gmail (correos).
- Alojamiento: Hostinger.
2. Cómo se comunican
| Desde | Hacia | Para qué |
|---|---|---|
| Tienda | API | Leer el catálogo y crear pedidos. |
| Tienda | Mercado Pago | El cliente paga en Checkout Pro (redirección, sin iframe) y vuelve a la página de confirmación. |
| Mercado Pago | API | Webhook que avisa el resultado del pago; la API verifica su firma. |
| Panel | API | Gestionar productos, tallas y pedidos con sesión JWT. |
| API | MySQL | Guardar y consultar todos los datos. |
| API | Gmail | Correos de pedido, pago aprobado, despacho y backups. |
3. Tecnologías
| Capa | Tecnología | Uso |
|---|---|---|
| Tienda y panel | HTML, CSS y JavaScript | Páginas estáticas, sin compilación. |
| API | Node.js 22 y Express 4 | Rutas REST. |
| Base de datos | MySQL con mysql2 | Consultas parametrizadas; los pedidos se crean dentro de una transacción. |
| Sesión del panel | jsonwebtoken y bcryptjs | Tokens JWT y contraseñas cifradas. |
| Seguridad HTTP | helmet y CSP | Cabeceras de seguridad en la API y en la tienda. |
| Pagos | SDK de Mercado Pago | Checkout Pro y webhook con firma HMAC. |
| Imágenes | multer y sharp | Subida de fotos y conversión a WebP: 1200 px y miniatura de 400 px. |
| Correos | nodemailer con Gmail | Avisos al comprador y a la tienda. |
| Tareas programadas | node-cron | Backup diario a las 2:00 a. m. (hora de Colombia). |
| Rendimiento | compression | Respuestas de la API comprimidas. |
| Integración continua | GitHub Actions | Pruebas con MySQL 8 antes de cada despliegue. |
| Monitoreo | UptimeRobot | Vigila un endpoint de salud que también comprueba la base de datos. |
4. Ciclo de un pedido
- Pendiente: el cliente confirma su carrito. El pedido recibe un identificador aleatorio (UUID), no un número consecutivo, para que nadie pueda ver pedidos ajenos cambiando el número en la URL. Si no se paga en 2 horas, vence.
- Confirmado: Mercado Pago aprueba el pago. El comprador y la tienda reciben el correo de pago aprobado.
- Despachado: el administrador guarda el número de guía y el comprador recibe el correo de despacho.
- Entregado. En cualquier momento el pedido también puede quedar cancelado.
5. Seguridad
- Contraseñas del panel cifradas con bcrypt.
- Sesión con JWT; al cerrar sesión el token queda revocado.
- Límite de solicitudes por IP en el inicio de sesión, el checkout, los pagos y los backups.
- La firma del webhook de Mercado Pago se verifica antes de cambiar el estado de un pedido.
- La tienda nunca recibe datos de tarjetas: el pago ocurre en Mercado Pago.
- Cabeceras de seguridad (helmet en la API; CSP en la tienda y en este sitio).
- Pedidos identificados por UUID en las URL públicas.
6. Respaldo y despliegue
- Backups: cada noche se hace un volcado de la base de datos (mysqldump), se comprime con gzip, se guarda 30 días y se envía por correo. También se puede lanzar uno a pedido desde el panel.
- Despliegue: cada cambio en la rama principal pasa primero por pruebas automáticas: arranque, salud, productos, un inicio de sesión rechazado y un pedido completo. Solo si pasan, se publica en Hostinger.
- Migraciones: los cambios de esquema corren solos al arrancar la API y están escritos para poder repetirse sin efectos.
7. Decisiones y límites conocidos
- El inventario no se descuenta con cada venta. Cada talla de cada color se marca como disponible o agotada desde el panel. Así el negocio controla lo que ofrece aunque también venda en su local.
- Las tallas son numéricas (35, 36, 37…). Tallas de ropa como S, M o L requerirían adaptar la plataforma.
- Una sola instancia de la API. La lista de sesiones revocadas y los límites de solicitudes viven en memoria; si algún día se ejecutaran varias copias de la API, habría que llevarlos a la base de datos.
- Sin facturación electrónica integrada por ahora.