Files
Omar Sánchez Pizarro 7289ad6c26 activity
Signed-off-by: Omar Sánchez Pizarro <omar.sanchez@pistacero.net>
2026-01-21 10:31:06 +01:00
..
2026-01-20 23:49:19 +01:00
2026-01-21 10:31:06 +01:00
2026-01-21 10:31:06 +01:00
2026-01-20 23:49:19 +01:00
fix
2026-01-21 00:31:05 +01:00
2026-01-21 02:20:13 +01:00
2026-01-21 02:20:13 +01:00
2026-01-21 02:20:13 +01:00
2026-01-21 02:20:13 +01:00

Backend - Estructura del Código

Este directorio contiene el backend de la aplicación Wallabicher, organizado en una estructura modular y mantenible.

Estructura de Carpetas

backend/
├── config/              # Configuración y constantes
│   └── constants.js     # Constantes del sistema (paths, puertos, límites)
├── middlewares/         # Middlewares de Express
│   ├── auth.js          # Autenticación básica
│   └── rateLimit.js     # Rate limiting
├── services/            # Servicios y lógica de negocio
│   ├── redis.js         # Cliente Redis y operaciones de caché
│   ├── webPush.js       # Gestión de notificaciones push (VAPID)
│   ├── websocket.js     # Gestión de conexiones WebSocket
│   ├── articleMonitor.js # Monitoreo de artículos nuevos
│   └── fileWatcher.js   # Vigilancia de cambios en archivos
├── routes/              # Rutas API organizadas por dominio
│   ├── index.js         # Rutas principales (stats, cache)
│   ├── workers.js       # Gestión de workers
│   ├── articles.js      # Artículos y búsqueda
│   ├── favorites.js     # Favoritos
│   ├── logs.js          # Logs del sistema
│   ├── config.js        # Configuración
│   ├── telegram.js      # Integración con Telegram
│   ├── push.js          # Notificaciones push
│   └── users.js         # Gestión de usuarios
├── utils/               # Utilidades
│   └── fileUtils.js     # Operaciones de archivos
└── server.js            # Archivo principal de entrada

Descripción de Módulos

Config (config/)

  • constants.js: Centraliza todas las constantes del sistema (paths de archivos, puertos, configuración de rate limiting, etc.)

Middlewares (middlewares/)

  • auth.js: Middleware de autenticación básica usando Redis para almacenar usuarios
  • rateLimit.js: Middleware de rate limiting usando Redis

Services (services/)

  • redis.js: Cliente Redis, inicialización, y funciones para trabajar con artículos y usuarios
  • webPush.js: Gestión de VAPID keys y envío de notificaciones push
  • websocket.js: Gestión del servidor WebSocket y broadcasting
  • articleMonitor.js: Monitorea Redis para detectar nuevos artículos y enviar notificaciones
  • fileWatcher.js: Vigila cambios en archivos (workers.json) y emite eventos WebSocket

Routes (routes/)

Cada archivo maneja un conjunto relacionado de endpoints:

  • index.js: /api/stats
  • workers.js: /api/workers (GET, PUT)
  • articles.js: /api/articles (GET, search)
  • favorites.js: /api/favorites (GET, POST, DELETE)
  • logs.js: /api/logs (GET)
  • config.js: /api/config (GET)
  • telegram.js: /api/telegram/threads (GET)
  • push.js: /api/push/* (public-key, subscribe, unsubscribe)
  • users.js: /api/users (GET, POST, DELETE, change-password)

Utils (utils/)

  • fileUtils.js: Funciones auxiliares para leer/escribir JSON y logs

Server (server.js)

Archivo principal que:

  1. Inicializa Express y el servidor HTTP
  2. Configura middlewares globales
  3. Registra todas las rutas
  4. Inicializa servicios (Redis, WebPush, WebSocket)
  5. Inicia monitoreo y watchers
  6. Arranca el servidor

Inicio del Servidor

npm start
# o para desarrollo con auto-reload
npm run dev

El servidor se inicia en el puerto definido en SERVER.PORT (por defecto 3001).

Flujo de Inicialización

  1. server.js carga y configura Express
  2. Inicializa VAPID keys para push notifications
  3. Crea el servidor WebSocket
  4. Registra todas las rutas API
  5. Inicializa Redis (conexión, rate limiter, usuario admin por defecto)
  6. Inicia el monitoreo de artículos nuevos
  7. Inicia el file watcher para workers.json
  8. Inicia el servidor HTTP

Notas de Migración

El código original en server.js (1190 líneas) ha sido dividido en módulos más pequeños y mantenibles. Cada módulo tiene una responsabilidad única:

  • Separación de responsabilidades: Cada archivo tiene un propósito claro
  • Reutilización: Servicios y utilidades pueden ser reutilizados fácilmente
  • Testabilidad: Cada módulo puede ser probado de forma independiente
  • Mantenibilidad: Es más fácil encontrar y modificar código específico