Aplicación web para que empresas PYME de logística controlen y gestionen los costes de Demurrage & Detention (D&D) de contenedores marítimos.
- ¿Qué es Fluster?
- Demo
- Características principales
- Stack tecnológico
- Estructura del proyecto
- Inicio rápido
- Desarrollo local (sin Docker)
- Datos de prueba (seed)
- Variables de entorno
- Pruebas
- Documentación
Las empresas PYME de logística (importadores, transitarios, transportistas) gestionan contenedores marítimos con hojas de cálculo, fotos por WhatsApp y correos dispersos. Cuando un contenedor supera los días libres acordados con la naviera, comienzan a acumularse costes de Demurrage (contenedor en puerto) y Detention (contenedor con el cliente), que pueden alcanzar cientos de euros por día.
Fluster centraliza todo el ciclo de vida del contenedor, calcula automáticamente los costes D&D según tarifas por tramos, y ofrece un semáforo de riesgo visual para actuar antes de que los costes se disparen.
| Entorno | URL |
|---|---|
| Frontend | https://fluster-frontend.onrender.com |
| Backend API | https://fluster-vd09.onrender.com |
| Documentación API (Swagger) | https://fluster-vd09.onrender.com/api-docs |
| Diseño Figma | Archivo de diseño |
| Prototipo interactivo | Prototipo navegable |
| Wireframes | Wireframes |
| Diagrama de flujo (FigJam) | Diagrama de Flujo — Fluster |
| GitHub Projects | Tablero de planificación |
- Ciclo de vida completo del contenedor — registro de eventos con foto, timestamp y código BIC a lo largo de los estados INACTIVO, PUERTO, CLIENTE y VUELTA_PUERTO.
- Cálculo automático de D&D — costes calculados en tiempo real mediante tablas de tarifas por tramos configurables por naviera.
- Semáforo de riesgo visual — indicador verde/naranja/rojo basado en los días libres restantes para anticipar costes.
- OCR con Tesseract.js — lectura y validación automática del código BIC del contenedor a partir de una foto.
- Generación de informes PDF — exportación de resumen de costes con jsPDF para cotejar con las facturas de las navieras.
- Control de acceso por roles — admin, gestor y operador con permisos diferenciados.
- Documentación interactiva — Swagger UI disponible en
/api-docs. - Tema claro/oscuro — alternancia de tema persistente en la interfaz.
- Despliegue con Docker Compose — entorno completo reproducible en un solo comando.
Fluster/
├── backend/ # API REST (Express + MongoDB)
│ ├── src/
│ │ ├── routes/ # Definición de endpoints
│ │ ├── controllers/ # Entrada/salida HTTP
│ │ ├── services/ # Lógica de negocio
│ │ ├── models/ # Esquemas de Mongoose
│ │ ├── middlewares/ # Auth, roles, errores
│ │ ├── scripts/ # Seed de datos
│ │ ├── app.js # App Express (sin arrancar el servidor)
│ │ └── index.js # Punto de entrada (arranque)
│ ├── tests/ # Tests unitarios y de integración (Jest)
│ └── Dockerfile
├── frontend/ # SPA (React + Vite)
│ ├── src/
│ │ ├── components/ # Atomic Design: átomos, moléculas, organismos
│ │ ├── pages/ # Vistas por ruta
│ │ ├── hooks/ # Hooks reutilizables
│ │ ├── services/ # Cliente HTTP (Axios)
│ │ └── styles/ # ITCSS + SCSS
│ ├── tests/ # Tests Vitest (unitarios) y Playwright (e2e/)
│ ├── nginx/ # Configuración del reverse proxy
│ └── Dockerfile
├── docs/ # Documentación del proyecto (01–10 + diseño)
├── .github/workflows/ # CI, CD, Docker y escaneo de seguridad
└── docker-compose.yml # Orquestación de los 3 servicios
Requisitos previos: Docker y Docker Compose instalados.
# 1. Clonar el repositorio
git clone https://github.com/Agsergio04/Fluster.git
cd Fluster
# 2. Copiar y configurar las variables de entorno
cp backend/.env.example backend/.env
# Editar backend/.env con los valores correspondientes
# 3. Levantar todos los servicios
docker compose up --buildUna vez iniciado, la aplicación estará disponible en http://localhost (puerto 80, servido por nginx). La API es accesible a través del proxy en http://localhost/api.
Si prefieres ejecutar los servicios directamente (por ejemplo, para desarrollar con recarga en caliente), necesitas Node.js 22+ y una instancia de MongoDB (local o Atlas).
# 1. Clonar el repositorio
git clone https://github.com/Agsergio04/Fluster.git
cd Fluster
# 2. Backend
cd backend
npm ci
cp .env.example .env # configurar MONGO_URI, JWT_SECRET (y CORS_ORIGIN si aplica)
npm run dev # arranca en http://localhost:3000 con recarga (nodemon)
# 3. Frontend (en otra terminal)
cd frontend
npm ci
cp .env.example .env # configurar VITE_API_URL=http://localhost:3000/api
npm run dev # arranca en http://localhost:5173 (Vite)El frontend de desarrollo (Vite) queda en http://localhost:5173 y llama al backend mediante la variable VITE_API_URL.
El backend incluye scripts para poblar la base de datos sin tener que crear los datos a mano:
cd backend
# Crear un usuario administrador inicial
npm run seed
# Poblar la BD con datos de demostración (usuarios, navieras, clientes,
# contenedores en distintos estados, ciclos y eventos)
npm run seed:datosTras npm run seed:datos, la consola muestra las credenciales de los usuarios de ejemplo (admin, gestor y operador) para iniciar sesión.
El archivo backend/.env debe contener las siguientes variables:
| Variable | Descripción | Ejemplo |
|---|---|---|
MONGO_URI |
URI de conexión a MongoDB Atlas | mongodb+srv://user:pass@cluster.mongodb.net/fluster |
PORT |
Puerto en el que escucha el servidor Express | 3000 |
JWT_SECRET |
Clave secreta para firmar los tokens JWT | una_clave_secreta_larga_y_aleatoria |
CORS_ORIGIN |
Orígenes permitidos por CORS, separados por comas. Si se omite, se permite cualquier origen (solo recomendable en local) | https://fluster-frontend.onrender.com |
El archivo frontend/.env debe contener:
| Variable | Descripción | Ejemplo |
|---|---|---|
VITE_API_URL |
URL base de la API que consume el frontend | http://localhost:3000/api |
| Ámbito | Comando | Herramienta |
|---|---|---|
| Backend (unitarios + integración) | cd backend && npm test |
Jest + mongodb-memory-server + Supertest |
| Backend (con cobertura) | cd backend && npm run test:coverage |
Jest |
| Frontend (unitarios) | cd frontend && npm test |
Vitest + React Testing Library |
| Frontend (end-to-end) | cd frontend && npm run test:e2e |
Playwright |
La integración continua (GitHub Actions) ejecuta los tests del backend y la build del frontend en cada push y Pull Request a main y dev.
| # | Documento | Descripción |
|---|---|---|
| 01 | Introducción | Origen, objetivos, análisis comparativo y alcance del MVP |
| 02 | Descripción del sistema | Visión general del sistema y sus componentes |
| 03 | Instalación | Guía de instalación y configuración del entorno |
| 04 | Guía de estilos | Convenciones de código, SCSS/ITCSS y Atomic Design |
| 05 | Diseño | Diagrama ER, casos de uso, diagramas de flujo, arquitectura y diseño de la API REST |
| 06 | Desarrollo | Secuencia de sprints, decisiones técnicas y fragmentos de código representativos |
| 07 | Pruebas | Estrategia de tests, cobertura y ejecución con Jest (backend) y Vitest (frontend) |
| 08 | Despliegue | CI/CD con GitHub Actions, configuración de Render y Docker |
| 09 | Manual de usuario | Guía de uso por rol: admin, gestor y operador |
| 10 | Conclusiones | Valoración del proyecto, mejoras futuras y aprendizajes |
- Diseño de Interfaces Web — índice con todos los RA y sus evidencias:
docs/diseño/README.md. - Despliegue de Aplicaciones Web — criterios C1, C2, C7 y C8 con evidencias (RA1 a recuperar):
docs/08-despliegue-eval.md.
Las contribuciones son bienvenidas. Consulta la guía de contribución completa para los detalles de entorno, convención de commits y proceso de Pull Request, y respeta el Código de Conducta. En resumen, el flujo de trabajo es:
- Crear una rama desde
devcon un nombre descriptivo (feat/nombre-featureofix/descripcion-bug). - Desarrollar y añadir tests si corresponde.
- Abrir una Pull Request hacia
dev. Los checks de CI (lint + tests) deben pasar antes de hacer merge. - Las releases a producción se realizan mediante PR de
devamain.
Por favor, respeta el estilo de código existente y añade tests para cualquier nueva funcionalidad: Jest en el backend (backend/tests/) y Vitest en el frontend (frontend/tests/).
Los cambios entre versiones se documentan en el CHANGELOG.
El proyecto incorpora medidas de seguridad básicas: autenticación JWT con roles, contraseñas hasheadas con bcrypt, cabeceras HTTP con Helmet, CORS configurable, escaneo de dependencias con Dependabot y de vulnerabilidades con Trivy en CI.
Si descubres una vulnerabilidad, no abras un issue público: sigue la política de seguridad.
Distribuido bajo la licencia MIT. Consulta el archivo LICENSE para más información.