← Tutti gli articoli

Sanity CMS in produzione: 6 mesi dopo, cosa rifaremmo e cosa no

04 March 20242 min di lettura

Studio personalizzabile, GROQ, real-time collaboration. I punti che ci hanno convinto e i tre dove abbiamo sudato.

A settembre 2023 abbiamo messo in produzione Sanity per un cliente nel B2B services che voleva un sito multilingua con redazione interna di 4 persone. Sei mesi dopo, possiamo dire cosa funziona e cosa abbiamo dovuto piegare.

Cosa ci ha convinto

  • Studio: l'editor è personalizzabile in TypeScript. Non è un visual builder ostile a chi sviluppa — è un'app React che configuri.
  • Schemi tipizzati: definisci il modello dati una volta e ottieni tipi TS auto-generati per il frontend. Niente più drift fra CMS e codice.
  • Real-time collaboration: due editor sullo stesso documento vedono modifiche live. Notion-like, gratis dal box.
  • GROQ: il query language è verboso ma potentissimo, soprattutto per query con join e proiezioni.

Dove abbiamo sudato

1. Internazionalizzazione

Sanity ha 3 strategie i18n: campi localizzati, documenti separati, plugin. Nessuna è il default. Abbiamo provato tutte e tre prima di trovare quella giusta per il cliente (campi localizzati per testi corti, documenti separati per pagine intere).

2. Costi a scaglioni

Il free tier copre molto, ma supera 10 GB di asset o 10k API requests/mese e si entra nel piano Growth (99 USD/mese). Abbiamo dovuto cachare aggressivamente lato Next.js (revalidate + tags) per non scoppiare la fattura.

3. Studio embedding

Hostare lo Studio dentro la stessa app Next.js (sotto /studio) sembra elegante, ma complica i deploy: la build dello Studio è pesante e fa esplodere i tempi su Vercel. Lo abbiamo separato come app a sé, deploy indipendente.

Cosa rifaremmo

Sanity sì, ma solo se il cliente ha una redazione che lavora il sito quasi quotidianamente. Per progetti dove il CMS si tocca una volta al mese, Markdown in repo o un CMS più semplice (es. Decap) costano meno e sono più che sufficienti.