Perché WebBlocks CMS è un pacchetto Composer
Un CMS può essere eseguito all'interno di un prodotto Laravel senza assumerne la proprietà.
Quando un prodotto Laravel esistente necessita di pagine, navigazione, contenuti multimediali, localizzazione e un flusso di lavoro editoriale, la prima domanda viene spesso formulata come segue: il CMS dovrebbe essere parte dell'applicazione o un servizio headless separato?
L'inquadratura ignora un'utile opzione centrale. Un CMS può essere eseguito all'interno dell'applicazione Laravel senza diventare l'applicazione stessa.
WebBlocks CMS è distribuito come pacchetto Composer fklavyenet/webblocks-cms. La scelta riguarda meno la comodità di installazione che la proprietà. Il pacchetto contribuisce con un sistema di contenuti; l'host rimane il prodotto Laravel.
Ciò che l'applicazione host continua a possedere
L'installazione del pacchetto non trasferisce la root del progetto al CMS. L'host possiede ancora il bootstrap, l'ambiente, la connessione al database, la cache, le code, la posta, le attività pianificate, la distribuzione, i backup, la root dei documenti pubblici e il codice specifico del prodotto.
Possiede anche il proprio dominio. Una piattaforma di apprendimento mantiene i suoi corsi e i suoi studenti. Un'applicazione commerciale conserva i propri ordini e clienti. Il CMS può pubblicare pagine di marketing o documentazione oltre a tali funzionalità, ma non dovrebbe trasformare i concetti di host in concetti CMS semplicemente perché entrambi vengono eseguiti in un unico processo.
Questo è il motivo per cui gli spazi dei nomi sono importanti. WebBlocks utilizza /webadmin; non presuppone che /admin dell'host appartenga al CMS. Le risorse CMS statiche utilizzano /cms. I nomi delle rotte, le visualizzazioni, le chiavi di configurazione, le tabelle e l'autorizzazione richiedono una proprietà altrettanto chiara.
Contributo del pacchetto
Laravel rileva il fornitore di servizi di pacchetto tramite Composer. Il pacchetto registra i percorsi, le visualizzazioni dello spazio dei nomi, le traduzioni, le migrazioni, le impostazioni predefinite di configurazione, i comandi, le policy e le risorse statiche.
Il risultato è un insieme sostanziale di funzionalità: pagine, layout, blocchi, contenuti multimediali, localizzazione, revisioni, Shared Slots, navigazione, API di contenuto e interfaccia operatore, senza copiare controller e modelli CMS nella directory app/ dell'host.
Questo è importante durante gli aggiornamenti. Il codice di proprietà del pacchetto ha una posizione canonica. Un file CMS rimosso può scomparire con la sostituzione del pacchetto invece di persistere come una vecchia sostituzione a livello di root. I file host e i file del pacchetto possono seguire cicli di vita di rilascio diversi perché la proprietà è esplicita.
Perché non richiedere un servizio separato?
Un servizio headless acquista un vero isolamento. Può scalare, implementare e fallire in modo indipendente e più prodotti possono utilizzarlo attraverso stack tecnologici. Quando tali proprietà sono requisiti, un limite HTTP potrebbe essere quello giusto.
Crea inoltre lavoro di integrazione. L'autenticazione, l'autorizzazione, le anteprime, il routing localizzato, l'accesso ai media, l'invalidazione della cache, il coordinamento della distribuzione e la gestione degli errori oltrepassano i confini della rete. Il contenuto che necessita di dati dell'applicazione richiede in genere un'altra API o un livello di sincronizzazione.
Un pacchetto effettua un'operazione diversa. Riutilizza il runtime Laravel dell'host e può partecipare alle stesse transazioni, policy, routing e distribuzione. Per un prodotto Laravel con un proprietario operativo, questo potrebbe essere un confine più semplice.
La separazione operativa dovrebbe ripagarsi da sola. Un servizio di rete non è automaticamente più disaccoppiato quando ogni flusso di lavoro utile dipende ancora da un collante personalizzato tra il servizio e il prodotto.
Condividere un processo non significa isolamento
Il confezionamento come pacchetto Composer ha costi reali. Il CMS e l'host condividono un processo PHP, un risolutore di dipendenze, una versione di Laravel e un server di database. Route, middleware, configurazione, tabelle, presupposti di autenticazione e percorsi pubblici possono entrare in conflitto se i confini vengono progettati incautamente.
Anche la proprietà dello schema necessita di disciplina. Le migrazioni dei pacchetti possono creare tabelle CMS, ma non devono dedurre la proprietà di una tabella host esistente perché un nome corrisponde. Le installazioni parziali necessitano di rilevamento e riparazione esplicita, non di ipotesi distruttive.
Gli utenti sono un buon esempio. Un host condiviso può utilizzare una tabella users per l'identità mentre l'accesso CMS è rappresentato da ruoli CMS e assegnazioni di sito. Un amministratore host non è automaticamente un super amministratore CMS ed è vero anche il contrario. Il riutilizzo dell'identità non deve far crollare due sistemi di autorizzazione.
Questi non sono argomenti contro il modello di pacchetto. Sono il lavoro necessario per renderlo reale.
Un pacchetto è un limite di proprietà, non un limite di isolamento.
Testare il confine all'esterno del sito principale
Un test pratico rileva molti errori di architettura: immagina di installare il pacchetto in un prodotto Laravel non correlato.
Vedrebbe un percorso, un percorso di risorsa, un dominio, un record seed o una definizione di applicazione che appartiene solo all'host originale? Il CMS richiederebbe all'host di adottare il proprio URL di amministrazione o la catena di creazione del frontend? Un aggiornamento sovrascriverebbe il contenuto o la configurazione di proprietà del sito?
Se la risposta è sì, la funzionalità probabilmente ha oltrepassato i limiti del pacchetto.
WebBlocks applica la stessa regola alle applicazioni eseguibili. Il core CMS fornisce un registro generico e un modello di autorizzazione; le definizioni dell'applicazione host reale appartengono al database o al repository di tale installazione. Il pacchetto non dovrebbe introdurre di nascosto le convenzioni del filesystem di un cliente in ogni consumatore.
La forma dell'installazione è una promessa architettonica
L'installazione con Composer diventa una promessa architetturale solo quando la proprietà rimane chiara dopo l'installazione:
- l’host possiede l’applicazione Laravel e le operazioni;
- il pacchetto possiede il codice CMS riutilizzabile;
- i contenuti del sito e le personalizzazioni appartengono all’installazione;
- i dati di dominio dell’host restano dati di dominio dell’host;
- l’autenticazione può essere condivisa, mentre l’autorizzazione resta limitata al proprio ambito;
- la capacità di pubblicazione non diventa implicitamente autorità di distribuzione.
Questa promessa è il motivo per cui WebBlocks CMS è un pacchetto. L'obiettivo non è far sì che ogni applicazione Laravel assomigli a WebBlocks. Si tratta di aggiungere una pubblicazione strutturata a un'applicazione che deve restare riconoscibilmente propria.
Scegliere un servizio separato quando operazioni indipendenti, riutilizzo tra stack o isolamento di sicurezza giustificano il limite della rete. Scegli un pacchetto quando contenuto e prodotto necessitano di una stretta integrazione e un runtime Laravel è un vantaggio piuttosto che una responsabilità.
Quali responsabilità devi separare e quali diventano più difficili quando lo fai?