La parte di scheduling di uno scheduler per i social media e un weekend. Una coda, un worker, un cron. Non e davvero difficile, ed e per questo che la stima e sempre sbagliata.
Tutto cio che costa e dall’altra parte.
La parte facile
Una tabella di post con un orario programmato, un worker che si attiva, trova i post in scadenza e li pubblica. Aggiungi un retry ed e fatta.
Se stai costruendo questo come progetto di apprendimento o per una sola piattaforma che controlli, smetti di leggere. Il resto riguarda cosa succede quando sono coinvolti account reali e piattaforme multiple.
Il modello di dati di cui hai davvero bisogno
Piu stati di quanto ci si aspetti:
- bozza, creato ma non messo in coda
- programmato, in coda per un orario
- in elaborazione, inviato alla piattaforma, esito sconosciuto
- pubblicato, confermato
- fallito, con un motivo
- parziale, pubblicato per alcuni target e non per altri
Lo stato “in elaborazione” esiste perche diverse piattaforme accettano un post e lo pubblicano in modo asincrono. Un 200 non e una pubblicazione, e l’esito arriva dopo, fuori banda. Senza questo stato la tua interfaccia dichiara successo ed e a volte sbagliata.
Lo stato “parziale” esiste perche un post di solito ha come target diverse piattaforme. Tre riescono, una fallisce. Ne “pubblicato” ne “fallito” e vero, e forzarlo in uno dei due produce un prodotto che mente ai suoi utenti.
Serve anche una riga per ogni target invece di un singolo stato sul post, perche il fallimento e specifico per piattaforma.
Fusi orari
Memorizza l’istante e il fuso IANA, non un offset.
“Ogni giorno feriale alle 9 ora locale” e un istante UTC diverso prima e dopo un cambio dell’ora legale. Memorizzare solo l’UTC funziona fino a marzo, poi tutto si sposta di un’ora e le segnalazioni di bug diventano confuse perche e corretto per meta dell’anno.
Il lavoro sulle piattaforme
Qui e dove la stima si rompe. Per piattaforma:
Un flusso OAuth separato. Scope diversi, durate dei token diverse, schermate di consenso diverse.
Un job di refresh separato. Questo e quello che fa male. I token scadono, il refresh fallisce silenziosamente e nessuno se ne accorge finche un post programmato non viene pubblicato. Serve un refresh programmato, il monitoraggio dei fallimenti di refresh, uno stato di connessione interrotta e un flusso di riconnessione. E piu lavoro del flusso OAuth stesso.
Una pipeline media separata. Una piattaforma recupera un URL, una vuole un upload a blocchi ripristinabile, una vuole dimensioni o codec specifici. Dovrai fare hosting e possibilmente transcodifica.
Un rate limit separato, con la propria finestra e il proprio comportamento quando viene superato.
La revisione dell’app. Diverse piattaforme bloccano la pubblicazione dietro una revisione che coinvolge la tua app, una privacy policy e a volte un video dimostrativo. E tempo di calendario che non controlli, e puo essere rifiutata.
Cambiamento perpetuo. Le versioni delle API vengono deprecate, i campi rinominati, i permessi irrigiditi, secondo i tempi delle piattaforme. Ognuno e lavoro non pianificato con una scadenza che non hai fissato tu.
Moltiplica per il numero di piattaforme. Poi continua a pagarlo, per sempre.
Le regole di pubblicazione
Oltre alla consegna, cio che gli utenti vogliono davvero e non pubblicare qualcosa che verra rifiutato. Cio significa codificare per piattaforma:
- Limiti di caratteri
- Numero, dimensioni, formati, durate, proporzioni dei media
- Quali tipi di post richiedono media
- Quali formati esistono affatto
E convalidare alla creazione invece che alla pubblicazione, perche un fallimento al momento della pubblicazione e uno che l’utente scopre dopo che il momento e passato.
Costruiscilo se
- Pubblichi su esattamente una piattaforma, permanentemente
- La pubblicazione e il tuo prodotto e il tuo elemento distintivo
- Ti serve una profondita ben oltre la pubblicazione, come la gestione degli annunci
Non costruirlo se
La pubblicazione e una funzionalita di qualcos’altro che stai costruendo e raggiunge tre o piu piattaforme. Il costo non e la costruzione, e la manutenzione, e la manutenzione scala con il numero di piattaforme mentre il tuo team no.
L’alternativa
Un’unica integrazione, dove il turnover delle piattaforme e problema di qualcun altro.
- URL base:
https://app.bulkpublish.com - Autenticazione: chiave API, oppure OAuth 2.1 se agisci per conto degli account dei tuoi utenti
- Superficie: 59 endpoint documentati
- Piattaforme: 15
- Convalida: limiti controllati alla creazione, non alla pubblicazione
- SDK: Node e Python, piu una collezione Postman e un server MCP
| Free | Pro | Business | |
|---|---|---|---|
| Richieste API/giorno | 30 | 5.000 | 50.000 |
| Chiavi API | 1 | 5 | 10 |
La versione breve
La coda e un weekend. Gli stati, i fusi orari e un flusso OAuth piu un job di refresh piu una pipeline media per piattaforma sono il progetto vero, e il turnover delle piattaforme fa sì che non finisca mai. Costruiscilo se la pubblicazione e il tuo prodotto o se resti su una piattaforma per sempre. Altrimenti, l’integrazione che non mantieni vale piu di quella che mantieni.