Personalizzazione estrema di Strapi 5: Integrazione di Quill e architettura multi-tenant

Nel settembre 2025, il rilascio di "Strapi 5" ha portato importanti aggiornamenti per gli sviluppatori. Segnando una netta rottura con le strutture dati di Strapi 4, ha introdotto cambiamenti radicali, rinnovato le API multilingua e incrementato le prestazioni. Pur essendo diventato uno strumento più semplice e potente, alcune configurazioni predefinite presentavano margini di miglioramento.

In particolare, l'editor "Blocks" predefinito (basato su Lexical) è moderno ma manca di strumenti avanzati per la modifica di tabelle e la decorazione del testo, spesso necessari per la progettazione di layout ricchi. Non era in grado nemmeno di creare una tabella semplice. Sebbene i bordi delle tabelle siano meno comuni nel design occidentale, in Giappone sono essenziali per creare pagine strutturate e facili da leggere.

Inoltre, Strapi 5 è privo di multi-tenancy nativo. È possibile avviare container separati per ciascuna organizzazione, ma eseguire un database PostgreSQL dedicato per ciascun tenant è costoso. Per ottenere una multi-tenancy a costi ridotti, ho personalizzato il backend. Ecco come ho modificato l'ambiente Strapi 5 per il blog "kuro.boo" al fine di ottenere un'ottima esperienza di editing e un'elevata efficienza di gestione.

1. Risoluzione delle peculiarità dell'input in giapponese (IME)

Strapi è basato su React, il che comporta determinati comportamenti della UI. L'editor principale di Strapi 5 presentava problemi minori nella gestione degli eventi IME in giapponese, provocando salti del cursore durante la digitazione. Ho testato tre diversi IME su macOS (quello predefinito di Apple, Google Japanese Input e Kawasemi), ma i problemi relativi al cursore sono rimasti poiché l'editor intercettava eventi della tastiera non necessari. All'inizio dovevo scrivere gli articoli in editor esterni come Zed e fare copia-incolla. Era decisamente troppo noioso.

2. Gestione di immagini multiple

Gli articoli necessitano di qualcosa di più del semplice testo e delle immagini di copertina. Per prima cosa ho provato il seguente plugin:

TipTap

TipTap è popolare e supporta più immagini, ma la sua implementazione richiedeva l'inserimento di blocchi di input separati per ogni singola immagine e paragrafo di testo. Questo approccio sembrava datato e ben lontano da una vera esperienza WYSIWYG, facendomi rimpiangere gli agili strumenti di layout di Dropbox Paper (che utilizzo di frequente).

3. Transizione a Quill

Poiché Lexical e TipTap non soddisfacevano le mie esigenze, ho preso in considerazione Quill. Con la release v2, Quill offre un'eccellente flessibilità. Le sue funzioni WYSIWYG sembravano promettenti, ma mancava ancora del supporto nativo per le tabelle avanzate. Per risolvere questo problema, ho integrato "quill-better-table" (dopo una giornata di debugging). Questo plugin permette di aggiungere/eliminare righe e colonne tramite clic destro, unire celle e applicare stili personalizzati direttamente all'interno del pannello di amministrazione di Strapi. Aspetto cruciale, queste tabelle vengono salvate come codice HTML standard, facilitandone il rendering nel frontend Astro.

Ciò ha risolto sia la modifica delle tabelle che i problemi di input IME, garantendoci un pannello editor WYSIWYG altamente funzionale all'interno di Strapi:

4. Aggiunta dell'upload delle immagini tramite Drag-and-Drop

Per rendere la scrittura più fluida, ho aggiunto una funzione di trascinamento e rilascio: trascinando un'immagine o incollandola dagli appunti viene richiamata automaticamente l'API di upload di Strapi, registrando l'elemento nella libreria multimediale e inserendolo nell'editor. (Nota: dato che il drag-and-drop non mostra messaggi di errore dettagliati per i file troppo grandi, dobbiamo comunque fare attenzione ai limiti di dimensione dei file).

5. Multi-Tenancy basata su Schema

Per gestire più siti in una singola istanza di Strapi senza avviare container di database separati, ho implementato il cambio di schema del database (DATABASE_SCHEMA) all'interno dello stesso database. Questo approccio contiene i costi del database pur mantenendo ambienti separati e sicuri per ogni tenant.

6. Un flusso di lavoro locale-first con generazione di siti statici (SSG)

Se da un lato l'esecuzione continua di un server CMS 24 ore su 24 e 7 giorni su 7 è ideale per i team che collaborano, dall'altro comporta costi inutili e rischi di sicurezza per blog personali o siti poco aggiornati. Di conseguenza, ho modificato l'architettura di deployment:

1. Avviare l'istanza locale di Strapi solo durante la scrittura o la modifica di articoli.
2. Eseguire una build di sviluppo che compila i contenuti di Strapi in pagine Astro statiche, copiando le immagini nella cartella di build e aggiornando i relativi link.
3. Arrestare l'istanza locale di Strapi e distribuire il sito completamente statico su Cloudflare Pages.

Questa configurazione fa sì che il nostro sito pubblico sia ospitato interamente sulla rete edge di Cloudflare. Carica in modo estremamente rapido, non ha costi di hosting ed elimina i rischi di sicurezza dei database esposti pubblicamente. Su kuro.boo, per comodità, lascio l'istanza Strapi locale in esecuzione sul mio computer locale, poiché non comporta costi di hosting.

Confronto tra impostazioni predefinite e personalizzate:

Conclusione

Ho anche risolto un bug minore per cui qualsiasi piccola modifica aggiornava la data di pubblicazione dell'articolo, spingendo i post più vecchi all'inizio del feed. Ho aggiunto un campo dedicato `publishedAt` e ho ordinato i contenuti in base a esso. Sebbene la modifica diretta del codice sorgente di Strapi 5 possa complicare i futuri aggiornamenti, questo livello di personalizzazione è ciò che rende le piattaforme headless CMS così potenti. Mi ha permesso di creare un ambiente di editing su misura per le mie esigenze.

Fonti:

・Documentazione di Strapi 5

・Quill - Rich Text Editor

・quill-table-better (GitHub)