Chiunque gestisca un blog basato su un generatore di siti statici come Jekyll conosce la routine: apri l’editor di codice, scrivi in Markdown, avvii un server locale per l’anteprima, fai un commit su Git e infine un push sul repository.
È un flusso di lavoro potente e flessibile, ma non sempre il più immediato, specialmente quando l’ispirazione arriva e si vorrebbe solo iniziare a scrivere senza barriere.
E se potessimo eliminare tutti i passaggi intermedi? Se fosse possibile scrivere, modificare e pubblicare un articolo direttamente dal browser, con un’esperienza simile a quella di una piattaforma di blogging tradizionale, ma conservando la velocità e la sicurezza di un sito statico?
Questa è stata la domanda che mi ha spinto a sviluppare una delle funzionalità più interessanti di questo sito: un editor di blog integrato.
L’Idea: un ponte tra scrittura e pubblicazione
L’obiettivo era semplice: creare un’interfaccia web che permettesse di gestire i contenuti del blog in modo visuale.
Un luogo dove poter vedere la lista degli articoli esistenti, aprirli per modificarli, o creare un nuovo post da zero, con un’anteprima in tempo reale di ciò che si sta scrivendo.
Il tutto, senza mai lasciare il sito.
Per farlo, ho unito tre tecnologie fondamentali che già alimentavano il blog:
- Jekyll – il motore che trasforma semplici file di testo in un sito web completo;
- GitHub – la piattaforma che non solo ospita il codice sorgente del sito, ma anche tutti i contenuti, ovvero i file Markdown che costituiscono gli articoli;
- JavaScript – il linguaggio che dà vita al tutto, eseguito direttamente nel browser.
Come funziona? La magia delle API e di OAuth 2.0
Il vero cuore del progetto è l’interazione tra il sito e GitHub, resa possibile dalle API (Application Programming Interfaces) che GitHub stesso mette a disposizione.
Pensiamo alle API come a un cameriere in un ristorante:
noi (l’editor nel browser) non andiamo direttamente in cucina (i server di GitHub) a preparare il piatto (creare o modificare un file).
Invece, diamo un ordine al cameriere (chiamiamo una funzione dell’API), e lui si occupa di comunicare con la cucina e portarci il risultato.
Ma come fa GitHub a sapere che siamo davvero noi a dare gli ordini?
Qui entra in gioco OAuth 2.0, un protocollo di autorizzazione standard.
Spiegarlo con una metafora è semplice: invece di dare la password del mio account GitHub all’editor (cosa che sarebbe insicura), lo autorizzo tramite un processo di login.
GitHub fornisce al mio editor una “chiave temporanea” con permessi limitati.
Questa chiave permette all’editor di compiere azioni specifiche (come leggere e scrivere file nel repository del blog) per mio conto, senza mai conoscere le mie credenziali.
Una volta ottenuta l’autorizzazione, l’editor può:
- Elencare i post → chiedendo a GitHub la lista dei file nella cartella
_posts; - Leggere un articolo → recuperando il contenuto di un file specifico;
- Salvare o creare un post → inviando il nuovo testo a GitHub per creare un nuovo file o aggiornarne uno esistente.
Ogni volta che un file viene modificato o aggiunto, le GitHub Actions si attivano automaticamente, rigenerano il sito con Jekyll e pubblicano la versione aggiornata.
Il ciclo è completo.
Più di un semplice editor
Costruire questo strumento non è stato solo un esercizio tecnico, ma una riflessione su come possiamo modellare gli strumenti per adattarli al nostro modo di lavorare.
Ha trasformato la gestione del blog da un processo da “sviluppatore” a un’esperienza da “scrittore”, abbattendo l’attrito tra l’idea e la sua pubblicazione.
È la dimostrazione che, combinando le giuste tecnologie, possiamo creare soluzioni personalizzate che uniscono il meglio di due mondi:
la robustezza e il controllo degli strumenti per sviluppatori con la semplicità e l’immediatezza delle applicazioni che usiamo tutti i giorni.