El calendario de lanzamientos de My Comics Collection se actualiza cada mañana a las 9h hora de París mediante un cron-job externo que consulta la API pública Metron.cloud (licencia CC-BY-SA 4.0). El sistema sincroniza las nuevas solicitaciones, actualiza las fechas modificadas, descarga las portadas faltantes en una caché de disco local y notifica internamente a los usuarios Premium cuya pull list se ve afectada.
El calendario de lanzamientos se basa en una arquitectura de 4 capas técnicas. Capa 1: Metron.cloud, la fuente de datos original, una base comunitaria colaborativa creada en 2018 que agrega las solicitaciones oficiales de los editores con licencia CC-BY-SA 4.0. Capa 2: un cron-job externo alojado en cron-job.org (servicio gratuito con timeout de 30s) que llama cada mañana a las 9h00 de París a un endpoint dedicado de la API de My Comics Collection. Capa 3: la API del servidor que recupera los nuevos datos de Metron a través de su REST API, actualiza la tabla MySQL upcoming_releases y desencadena la descarga asíncrona de las portadas faltantes. Capa 4: el frontend de la aplicación que consulta esta tabla en cada visita del usuario para mostrar el calendario actualizado.
La arquitectura del sistema: Metron → API → caché → usuario
Este diseño de 4 capas separa de forma limpia las responsabilidades: Metron gestiona el dato fuente (que consumimos legalmente a través de su licencia), el cron controla la frecuencia (controlamos cuándo sincronizamos), el servidor gestiona la persistencia (caché MySQL + disco) y el frontend gestiona la visualización. Si una de las capas tiene una incidencia temporal, las demás continúan: la caché MySQL conserva los datos anteriores incluso si Metron está caído, lo que evita las páginas en blanco.
El cron-job diario: por qué a las 9h hora de París
La elección del horario de las 9h00 hora de París (UTC+1 o UTC+2 en verano) responde a varias restricciones operativas. (1) Desfase con el horario de EE. UU.: las 9h00 de París corresponden a las 3h-4h hora de Nueva York, cuando los editores estadounidenses han terminado sus actualizaciones nocturnas de la base Metron. A esa hora, el dato de Metron está fresco y estable para las 24h siguientes. (2) Carga del servidor baja: las 9h de París es todavía hora valle para la mayoría de los usuarios de My Comics Collection, lo que evita que el cron-job compita con el tráfico pico de los usuarios. (3) Disponibilidad para la jornada: los usuarios francófonos que abren la aplicación a primera hora de la jornada (8h-11h) ven un calendario recién actualizado, lo que maximiza la calidad percibida.
Una excepción: para los usuarios de Asia/Pacífico que visitan a medianoche de París (por la mañana en su zona), el calendario puede mostrar datos del día anterior antes de la sincronización de las 9h. Es un trade-off consciente: optimizamos para la mayoría francófona de la UE en lugar de para la minoría de APAC.
El timeout de 30s y la arquitectura async fire-and-forget
Una restricción técnica del servicio gratuito cron-job.org es el timeout HTTP de 30 segundos. Si el servidor de My Comics Collection tarda más de 30s en responder, cron-job.org considera que es un fallo y envía una notificación de error. Ahora bien, la sincronización completa de Metron (recuperación de las 400+ solicitaciones, actualización de MySQL, descarga de las nuevas portadas) tarda normalmente 2-5 minutos, muy por encima del timeout.
La solución arquitectónica: el endpoint pull_list_sync_async utiliza un patrón fire-and-forget mediante la función PHP fastcgi_finish_request(). Concretamente, el servidor (1) recibe la llamada del cron, (2) valida el token X-Sync-Token, (3) responde HTTP 200 en menos de 100 ms, (4) cierra la conexión HTTP y (5) continúa el trabajo de sincronización en segundo plano. cron-job.org recibe su HTTP 200 dentro del timeout y queda satisfecho, mientras que el servidor termina la sincronización real a su propio ritmo.
Este patrón es elegante pero tiene una restricción: si la sincronización falla silenciosamente tras el fire-and-forget (timeout de MySQL, espacio de disco saturado para las portadas, etc.), cron-job.org no se enterará. Para mitigarlo, el servidor escribe un log en _logs/pull_list_cron.log en cada etapa, lo que permite diagnosticar a posteriori si una sincronización ha fallado.
La caché de disco de las portadas: por qué y cómo
Las portadas de cómics recuperadas desde Metron se almacenan en una caché de disco local del servidor (directorio cache/metron_covers/). Esta caché es crucial para la fiabilidad de la visualización. Antes de la implementación de la caché (sprint v5.105 a finales de abril de 2026), las portadas se referenciaban directamente a través del CDN de Metron, lo que daba como resultado imágenes rotas una de cada dos veces a causa de los límites de hotlinking impuestos por el CDN.
Con la caché de disco, el flujo de trabajo es: (1) el cron de sincronización desencadena la descarga de las portadas faltantes mediante un comando PHP curl; (2) cada portada se almacena con el nombre {slug}.jpg a 300×450 píxeles; (3) un proxy HTTP del lado del servidor sirve estos archivos a través de la URL /api.php?action=cover_proxy&slug=X, lo que evita por completo el CDN de Metron una vez que la portada está en caché. Resultado: tasa de visualización de las portadas > 99,5 %.
Rendimiento: cuánto cuesta una sincronización diaria en recursos
Para los curiosos técnicos, aquí están los órdenes de magnitud de una sincronización diaria típica en junio de 2026: (1) peticiones a Metron: 1 llamada REST por publisher (~10 publishers principales), es decir 10 peticiones HTTP en menos de 5 segundos; (2) volumen de datos: 400-600 KB de JSON procesado; (3) peticiones MySQL: ~1 200 INSERT IGNORE (una por solicitación, idempotente) en menos de 2 segundos; (4) descarga de portadas faltantes: normalmente 20-50 nuevas portadas al día, es decir 1-3 MB descargados en 30 segundos; (5) tiempo total de pared: 2-5 minutos al día; (6) coste mensual: marginal (ampliamente incluido en el hosting compartido OVH existente, sin coste adicional).
Esta frugalidad forma parte de la filosofía de My Comics Collection: la funcionalidad Pull List se ofrece a los usuarios gratuitos sin degradar la economía general de la aplicación, porque su coste marginal es insignificante. El Premium financia el mantenimiento y las evoluciones, no la consulta gratuita.