Il calendario delle uscite di My Comics Collection si aggiorna ogni mattina alle 9 ora di Parigi tramite un cron-job esterno che interroga l'API pubblica Metron.cloud (licenza CC-BY-SA 4.0). Il sistema sincronizza le nuove solicitation, aggiorna le date modificate, scarica le copertine mancanti in una cache su disco locale e notifica internamente gli abbonati la cui pull list è interessata.
Il calendario delle uscite si basa su un'architettura a 4 livelli tecnici. Livello 1: Metron.cloud, la fonte dati originale, un database comunitario collaborativo creato nel 2018 che aggrega le solicitation ufficiali degli editori con licenza CC-BY-SA 4.0. Livello 2: un cron-job esterno ospitato su cron-job.org (servizio gratuito con timeout di 30s) che chiama ogni mattina alle 9:00 ora di Parigi un endpoint dedicato dell'API My Comics Collection. Livello 3: l'API server che recupera i nuovi dati Metron tramite la loro REST API, aggiorna la tabella MySQL upcoming_releases e avvia il download asincrono delle copertine mancanti. Livello 4: il frontend dell'applicazione che interroga questa tabella a ogni visita dell'utente per mostrare il calendario aggiornato.
L'architettura del sistema: Metron → API → cache → utente
Questo design a 4 livelli separa nettamente le responsabilità: Metron gestisce i dati sorgente (che consumiamo legalmente tramite la loro licenza), il cron pilota la frequenza (controlliamo noi quando sincronizzare), il server gestisce la persistenza (cache MySQL + disco) e il frontend gestisce la visualizzazione. Se uno dei livelli subisce un'interruzione temporanea, gli altri continuano a funzionare: la cache MySQL conserva i dati precedenti anche se Metron è irraggiungibile, evitando così le pagine bianche.
Il cron-job quotidiano: perché alle 9 ora di Parigi
La scelta dell'orario delle 9:00 ora di Parigi (UTC+1 o UTC+2 in estate) risponde a diverse esigenze operative. (1) Fuso orario rispetto agli USA: le 9:00 a Parigi corrispondono alle 3:00-4:00 di New York, quando gli editori americani hanno terminato gli aggiornamenti notturni del database Metron. A quell'ora i dati Metron sono freschi e stabili per le successive 24 ore. (2) Carico server ridotto: le 9:00 di Parigi sono ancora ore di bassa affluenza per la maggior parte degli utenti My Comics Collection, il che evita che il cron-job entri in competizione con il traffico utente di picco. (3) Disponibilità per la giornata: gli utenti che aprono l'applicazione a inizio giornata (8:00-11:00) vedono un calendario appena aggiornato, massimizzando la qualità percepita.
Un'eccezione: per gli utenti in Asia/Pacifico che visitano il sito a mezzanotte ora di Parigi (mattina per loro), il calendario potrebbe mostrare i dati del giorno precedente prima della sincronizzazione delle 9:00. È un compromesso consapevole: si ottimizza per la maggioranza degli utenti europei piuttosto che per la minoranza APAC.
Il timeout di 30s e l'architettura async fire-and-forget
Un vincolo tecnico del servizio gratuito cron-job.org è il timeout HTTP di 30 secondi. Se il server My Comics Collection impiega più di 30s a rispondere, cron-job.org considera la richiesta fallita e invia una notifica di errore. Eppure la sincronizzazione completa con Metron (recupero delle 400+ solicitation, aggiornamento MySQL, download delle nuove copertine) richiede tipicamente 2-5 minuti: ben oltre il timeout.
La soluzione architetturale: l'endpoint pull_list_sync_async utilizza un pattern fire-and-forget tramite la funzione PHP fastcgi_finish_request(). In concreto, il server (1) riceve la chiamata del cron, (2) valida il token X-Sync-Token, (3) risponde con HTTP 200 in meno di 100 ms, (4) chiude la connessione HTTP e (5) prosegue il lavoro di sincronizzazione in background. cron-job.org riceve il suo HTTP 200 entro il timeout ed è soddisfatto, mentre il server completa la vera sincronizzazione con i suoi tempi.
Questo pattern è elegante ma ha un limite: se la sincronizzazione fallisce silenziosamente dopo il fire-and-forget (timeout MySQL, spazio disco esaurito per le copertine, ecc.), cron-job.org non ne sarà a conoscenza. Per mitigare il problema, il server scrive un log in _logs/pull_list_cron.log a ogni fase, permettendo una diagnosi post-mortem in caso di sincronizzazione fallita.
La cache su disco delle copertine: perché e come
Le copertine dei comics recuperate da Metron vengono memorizzate in una cache su disco locale del server (directory cache/metron_covers/). Questa cache è fondamentale per l'affidabilità della visualizzazione. Prima dell'introduzione della cache (sprint v5.105, fine aprile 2026), le copertine venivano referenziate direttamente tramite il CDN Metron: il che causava immagini non caricate una volta su due a causa dei limiti di hotlinking imposti dal CDN.
Con la cache su disco, il flusso di lavoro è: (1) il cron di sincronizzazione avvia il download delle copertine mancanti tramite un comando PHP curl; (2) ogni copertina viene salvata con il nome {slug}.jpg a 300×450 pixel; (3) un proxy HTTP lato server serve questi file tramite l'URL /api.php?action=cover_proxy&slug=X, aggirando completamente il CDN Metron una volta che la copertina è in cache. Risultato: tasso di visualizzazione delle copertine > 99,5%.
Performance: quanto costa una sincronizzazione quotidiana in termini di risorse
Per i curiosi tecnici, ecco gli ordini di grandezza di una sincronizzazione quotidiana tipica a giugno 2026: (1) richieste Metron: 1 chiamata REST per publisher (~10 publisher principali), ovvero 10 richieste HTTP in meno di 5 secondi; (2) volume dati: 400-600 KB di JSON elaborato; (3) query MySQL: ~1.200 INSERT IGNORE (una per solicitation, idempotente) in meno di 2 secondi; (4) download copertine mancanti: tipicamente 20-50 nuove copertine al giorno, ovvero 1-3 MB scaricati in 30 secondi; (5) tempo totale: 2-5 minuti al giorno; (6) costo mensile: marginale (ampiamente incluso nell'hosting OVH condiviso esistente, nessun costo aggiuntivo).
Questa frugalità fa parte della filosofia My Comics Collection: il costo marginale della Pull List è trascurabile, il che permette di includerla nell'abbonamento senza sovrapprezzo. L'abbonamento finanzia la manutenzione e gli sviluppi.
Domande frequenti
Ogni mattina alle 9, ora di Parigi. Un'attività pianificata esterna chiama allora il server, che recupera le nuove solicitations, aggiorna le date modificate, scarica le copertine mancanti e avvisa gli abbonati la cui pull list è interessata.
Quell'ora corrisponde alle 3 o 4 di notte a New York, quando gli editori americani hanno terminato gli aggiornamenti notturni: il dato è fresco e stabile per le 24 ore successive. Il carico del server è ancora basso, e gli utenti francofoni che aprono l'app a inizio giornata trovano un calendario aggiornato. Gli utenti dell'Asia-Pacifico possono vedere i dati del giorno prima, un compromesso consapevole.
Il sistema poggia su quattro livelli che separano le responsabilità: fonte dei dati, innesco quotidiano, server e visualizzazione. Se uno ha un incidente temporaneo, gli altri continuano. La cache del server conserva i dati precedenti, il che evita pagine bianche.
Prima dell'introduzione della cache, a fine aprile 2026, le copertine erano collegate direttamente dalla fonte e si vedevano male una volta su due a causa di limiti di caricamento. Ora vengono scaricate in 300 x 450 pixel e servite tramite un proxy locale. Il tasso di visualizzazione supera il 99,5 %.
Una sincronizzazione completa dura tipicamente da 2 a 5 minuti, perché elabora più di 400 solicitations e scarica da 20 a 50 nuove copertine al giorno. Il server risponde subito alla chiamata pianificata e prosegue il lavoro in background. Il costo è marginale, il che permette di includere la Pull List nell'abbonamento senza supplemento.