Perché abbiamo creato Osprey, il nostro CMS headless

La maggior parte dei CMS headless ti costringe a scegliere: uno strumento con editor visuale che tratta lo schema come un blob di database generato una volta, oppure una configurazione fatta in casa in cui ogni caricamento di pagina richiama dal vivo il CMS. Abbiamo creato Osprey, il nostro CMS headless, per toglierti questa scelta: uno schema dei contenuti versionato come il codice e un sito distribuito come file statici. Ecco cosa fa davvero il codice, non solo cosa dice la presentazione.

Gli schemi sono codice, non un blob di database

In Osprey una collezione si definisce in TypeScript e vive nello stesso repository del resto dell'applicazione. Significa lo stesso controllo di versione, la stessa revisione del codice e gli stessi tipi end-to-end che un team applica già al codice dell'applicazione, estesi al modello dei contenuti. L'interfaccia di amministrazione è una comodità per modificare le voci; non è mai la fonte di verità per lo schema.

I contenuti arrivano in fase di build, non a ogni richiesta

Il loader @osprey/astro recupera le voci pubblicate dall'endpoint REST pubblico di Osprey durante la build e le consegna alle content collection di Astro, senza bisogno di una chiave API per quella lettura pubblica. Il sito distribuito è HTML statico puro: Osprey è una dipendenza di build, non di runtime. Se una build gira mentre il CMS è lento o irraggiungibile, il loader mantiene le voci già in cache invece di fallire.

Private di default, invisibili se non autorizzate

Una collezione è esposta sull'API pubblica solo quando la sua regola access.read ammette esplicitamente un chiamante anonimo; tutto il resto resta privato. Una richiesta verso una collezione privata, o verso un documento non pubblicato, torna come un 404 invece di un errore di permesso, così l'API non conferma mai che una collezione privata esista.

I metadati SEO viaggiano con ogni voce

Ogni voce restituita dall'API pubblica porta con sé un oggetto SEO combinato: il titolo, la descrizione, i tag Open Graph e Twitter e l'URL canonico della voce hanno la priorità, e i valori predefiniti a livello di workspace completano ciò che manca. Lo stesso payload include la direttiva robots risolta e i link hreflang verso ogni traduzione pubblicata di quella pagina, così un frontend può generare i suoi meta tag senza ricostruire quella logica da zero.

Un solo deployment, tanti tenant

Osprey è multi-tenant: un singolo deployment può servire più siti, ciascuno delimitato al proprio tenant. Sulle rotte di contenuto pubblico, il tenant da cui leggere si risolve dall'header host della richiesta stessa, non da uno fornito dal chiamante, così una richiesta anonima non può leggere i contenuti di un altro tenant inviando un id diverso. Ogni query al database che l'API esegue è delimitata al tenant internamente, non lasciata alla memoria di ogni singolo handler.

Meccaniche GDPR, non solo una dichiarazione

Osprey include un endpoint per il diritto all'oblio che oscura i dati personali — invii di form, autori nell'audit log, account utente — per un'email o un id dato, delimitato a un singolo tenant. Un endpoint di export separato produce un manifesto completo dei contenuti di un tenant per le richieste di portabilità dei dati. Il gestore dei cookie integrato tratta come sempre attivi solo i cookie strettamente necessari e imposta ogni altra categoria su negata finché il visitatore non acconsente, con «rifiuta tutto» dello stesso peso visivo di «accetta tutto». Poiché Osprey è self-hosted, un team può anche eseguirlo interamente su infrastruttura europea; le garanzie dedicate di residenza dei dati nell'UE fanno parte del piano enterprise del prodotto, non di ogni installazione di default.

Headless per scelta

Osprey archivia i contenuti e li distribuisce come JSON; non ha opinioni sull'aspetto di un sito. Un team può costruire il frontend in Astro, Next.js o qualsiasi generatore di siti statici in grado di chiamare un'API REST, e usare Osprey esclusivamente come livello dei contenuti sottostante. I piani attuali, incluse le versioni self-hosted ed enterprise, sono elencati sulla pagina prodotto di Osprey.

Cosa fare

• Definisci il tuo modello dei contenuti come collezioni TypeScript e versionalo insieme al codice dell'applicazione.
• Imposta una regola access.read esplicita su ogni collezione che vuoi servire dall'API pubblica; lasciala non impostata per mantenerla privata.
• Aggiungi il loader @osprey/astro, oppure chiama direttamente l'API REST, così i contenuti arrivano in fase di build e non a ogni richiesta.
• Imposta i campi SEO per singola voce solo dove devono differire dai valori predefiniti del sito, e lascia che i predefiniti completino il resto.
• Usa gli endpoint integrati di export e diritto all'oblio per le richieste di portabilità e cancellazione dei dati, invece di costruirne di tuoi.
• Se l'hosting solo UE conta per la tua conformità, ospita Osprey su infrastruttura europea o chiedi delle garanzie di residenza del piano enterprise.

Fonti: pagina prodotto di Osprey, getosprey.dev.