Andare senza testa: casi d'uso e a cosa serve

Questo articolo è stato gentilmente supportato dai nostri cari amici di Storyblok, un simpatico CMS headless con un editor visivo, componenti nidificati e blocchi di contenuto personalizzabili per siti Web e app. Grazie!

Guardando indietro agli anni di sviluppo per il Web, ho utilizzato dozzine di diversi strumenti CMS sia standard che fatti in casa. Ho distribuito e creato molti siti WordPress e plug- in, nonché estensioni per siti CMS a servizio completo in .NET. Ma per me, tutto è cambiato quando ho sentito parlare per la prima volta di senza testa e ora, anni dopo, non potrei sentirmi più a mio agio nell'ecosistema senza testa .

Questo entusiasmo non viene dal nulla. Anche se potrebbe sembrare scoraggiante dare un senso a tutte le opzioni senza testa, ho perfezionato la mia strategia per diverse opzioni senza testa in ambienti diversi e mi sono familiarizzato con i soliti sospetti nello spazio senza testa. Passare a headless mi ha aiutato a evitare di imbattermi in blocchi stradali causati dalle limitazioni dei sistemi all-in-one più grandi.

La compartimentazione delle funzionalità in modo da poter raggiungere obiettivi complessi oggi e preparare la tua app per evolversi facilmente in futuro mi dà tranquillità. È stato un piacere contribuire a implementazioni e iterazioni di successo su servizi Web basati su soluzioni headless per aziende private e il governo dello stato della California.

In questo articolo, mi piacerebbe condividere alcuni degli utili suggerimenti e linee guida che ho imparato in questi anni, con la speranza che ti aiutino a dare un senso al mondo senza testa e a trovare i candidati giusti per i tuoi progetti. Ma prima di tuffarci, dobbiamo tornare un po' indietro nel tempo per capire cosa porta in tavola gli headless.

Prima senza testa

Solo pochi anni fa, i nostri flussi di lavoro sembravano concentrarsi su una gamma di strumenti, stack e tecnologie. Per CMS, utilizzavamo principalmente strumenti all-in-one. Includevano sia le funzioni di creazione del contenuto che di visualizzazione del contenuto.

Gli utenti di questi strumenti erano bloccati con il front-end fornito con il back-end. La tua capacità di personalizzare le cose era limitata. È possibile installare plug-in, ma tutti devono essere creati per il proprio strumento. Potresti scrivere codice personalizzato, ma solo nella lingua su cui è basato il tuo strumento e nei suoi vincoli.

Tutto è cambiato negli ultimi anni con i CMS headless che hanno guadagnato popolarità in tutto il settore.

Una rinascita di strumenti specializzati

Oggi abbiamo una fioritura di strumenti specializzati nella visualizzazione di creazione o presentazione di contenuti. Un CMS headless si concentra sul pezzo di creazione del contenuto e fornisce un modo per collegare uno strumento di presentazione del contenuto separato. La mancanza di un frontend rivolto all'utente è ciò che lo rende senza testa e gli dà la flessibilità di lavorare con qualsiasi strumento tramite la sua API.

Essere in grado di progettare il proprio frontend da zero è liberatorio per molti team di sviluppo. Potresti avere un team di ingegneri esperti nella fornitura di app di una pagina singola in Vue.js o siti generati statici a prova di proiettile con rendering rapido con 11ty. Tutti i più recenti framework di sviluppo web sono progettati per funzionare facilmente con dati strutturati che possono essere forniti da qualsiasi CMS headless.

Un CMS headless è uno strumento mirato. Ha meno responsabilità di una soluzione all-in-one. Gli endpoint API forniti da un CMS headless forniscono una netta separazione tra i sistemi in modo da poter sostituire le architetture front o backend in modo indipendente man mano che le cose si evolvono. Il tuo prodotto cresce, l'ecosistema di strumenti si espande, nuovi approcci diventano disponibili. I tuoi requisiti di back-end e front-end cambieranno. Se disponi di una configurazione senza testa, sarai in grado di adattarti più facilmente perché il front-end e il back-end sono già separati in modo pulito da un'API e puoi aggiornarli in modo indipendente.

Senza testa è giusto per me?

In particolare, headless ti offre la flessibilità di cui potresti aver bisogno per soddisfare requisiti impegnativi. Potrebbe essere difficile raggiungere i tuoi obiettivi se devi modificare pesantemente un prodotto all-in-one. Combinare uno strumento senza testa con un frontend più piccolo, diverso o fatto in casa potrebbe essere il modo più semplice per fornire i progetti desiderati e i flussi utente.

• Se desideri perfezionare ogni fase del flusso di pagamento del prodotto , puoi utilizzare un'opzione di commercio senza testa per ottenerlo,
• Se desideri ottimizzare pesantemente per Time to First Byte , potresti voler utilizzare un generatore di siti statici che ricostruisce il contenuto in base alle modifiche in base a un'API CMS senza testa,
• Se ospiti i tuoi strumenti e sei cauto riguardo alla sicurezza, potresti voler bloccare il tuo ambiente di creazione dietro il firewall e consumarlo senza testa da un frontend più semplice basato su Jamstack,
• Se stai offrendo lo stesso contenuto a una varietà di client, come web, app native o widget di terze parti, puoi costruirli in modo che comunichino tutti attraverso lo stesso CMS senza testa.

Se riesci a soddisfare i requisiti del tuo progetto in modo impeccabile con uno strumento all-in-one, le opzioni senza testa sono probabilmente un po' eccessive per te. Allo stesso modo, se il tuo team è perfettamente soddisfatto e esperto della tua attuale soluzione all-in-one, non devi davvero preoccuparti di dividere gli strumenti front-end e back-end. Tuttavia, se invece stai riscontrando i limiti dei tuoi strumenti, andare senza testa ti consentirà di affrontare direttamente i tuoi punti deboli.

Esempio: eCommerce senza testa

Diamo un'occhiata a una scelta senza testa specifica: puoi integrare una piattaforma di eCommerce esistente, come Shopify, come flusso completo che si occupa dell'intero processo di pagamento, oppure puoi utilizzare un'opzione senza testa fornita anche da Shopify.

• Nel primo caso, il tuo design farà molto affidamento sui modelli di Shopify e sulle funzionalità pronte all'uso, quindi sarà possibile regolare il flusso di pagamento, ma piuttosto limitato.
• In quest'ultimo caso, puoi progettare il tuo flusso di pagamento nel modo che preferisci e farai affidamento su Shopify per eseguire semplicemente la transazione finanziaria.

La differenza significativa è che l'opzione senza testa richiederà di creare ogni singola vista che vede il tuo utente. Ancora una volta, se sembra una seccatura senza vantaggi, probabilmente non hai bisogno di una soluzione senza testa.

Una squadra che ha bisogno della versione senza testa apprezzerà la libertà che offre. Il tuo design non avrà vincoli e sarai in grado di controllare ogni pixel di ogni vista. Avrai il controllo totale di tutto il codice in esecuzione sui dispositivi dei tuoi utenti, così potrai tracciare, ottimizzare e velocizzare letteralmente ogni singola interazione.

Allo stesso tempo, stai ancora lasciando l'elaborazione delle transazioni alla tua soluzione di eCommerce senza testa, quindi stai ottenendo i vantaggi del loro sistema di back-end.

La conclusione è: se stai lottando con i colli di bottiglia all'interno della tua attuale soluzione di eCommerce, che si tratti di un front-end pesante, di un'interfaccia utente complessa o semplicemente di un design inaccessibile, un'opzione senza testa renderà più facile per il tuo team risolvere questi problemi. Allo stesso modo, se sembra che renderà più facile per il tuo team aumentare la canalizzazione di conversione rendendo l'implementazione di nuove funzionalità più rapida e agevole, allora è una buona idea considerare anche l'opzione senza testa.

Evitando il blocco con un'unica piattaforma

Considerando lo stato attuale del front-end, disaccoppiare i veicoli di authoring e di distribuzione dei contenuti è il modo più sicuro per progettare le cose in un mondo in cui le opzioni per gli strumenti front-end e back-end sono in continua espansione. Non è raro che gli ambienti di creazione e lettura abbiano insiemi di requisiti diversi, quindi la possibilità di scegliere strumenti che li affrontino separatamente offre opzioni migliori per entrambe le parti.

Le configurazioni basate su Jamstack sono abilitate dalle API, quindi sono spesso legate a un CMS headless. Tuttavia, fare una scelta senza testa non richiede un front-end Jamstack . Naturalmente, se lo desideri, puoi comunque eseguire del codice lato server.

Ad esempio, ho aiutato a creare alcuni siti che eseguono Node.js ed Express che utilizzano API back-end come Wordnik.com e questo modello popolare funziona senza problemi. Avere accesso ai tuoi dati tramite le API rende possibile abbandonare il tuo codice lato server in produzione, così puoi facilmente abbracciare approcci lato client come Jamstack se questo ha senso nel tuo progetto.

Il problema con le soluzioni "tutto in uno" è che ognuna di esse ha molti impegni incorporati. Ad esempio, devi impegnarti a supportare un database e un ambiente di programmazione o scegliere tra fornitori SaaS che lo fanno; inoltre, le modifiche al design dovranno avvenire all'interno dei temi e dei plug-in disponibili.

Con Headless, evadiamo dall'essere rinchiusi in un'unica piattaforma. Quindi, se hai bisogno di utilizzare un nuovo framework front-end per il tuo sito web, o vuoi rimuovere costose infrastrutture di produzione e utilizzare generatori di siti statici, o forse vuoi cambiare il tuo CMS senza ricostruire tutto il tuo front-end da zero, rispetto alle alternative , puoi ottenere tutto questo con molto meno attrito quando utilizzi un'opzione senza testa.

Diamo un'occhiata a un semplice esempio. Immagina che la tua organizzazione presenti una nuova iniziativa e un nuovo design e che i flussi vengano creati da zero per soddisfare le nuove esigenze degli utenti. Improvvisamente è necessario assemblare un nuovo stack tecnologico per soddisfare questi requisiti.

La scelta di un'opzione senza testa darà ai tuoi prodotti una possibilità migliore di longevità e renderà molto più semplice far sì che i tuoi contenuti si muovano senza problemi su più canali di distribuzione.

“

In questi casi, dovrai cercare una soluzione pronta all'uso perfetta che corrisponda perfettamente alle tue esigenze o compromettere alcuni dei requisiti di progettazione e flusso utente in modo che funzioni abbastanza bene. Ma se i tuoi requisiti di progettazione o prestazioni sono severi, potrebbe essere più facile raggiungere questi obiettivi andando senza testa.

La linea di fondo è che ci sono molti casi d'uso quando si sceglie un'opzione senza testa che darà ai tuoi prodotti una migliore possibilità di longevità , oltre a rendere molto più semplice far sì che i tuoi contenuti si muovano senza problemi in più canali di distribuzione. Essere in grado di consumare i tuoi contenuti come dati strutturati gli consente di prosperare sul tuo sito Web, nelle tue app native e di essere sindacato a fonti esterne.

Non tutto deve essere senza testa

Potrebbe sembrare che senza testa sia sempre un'opzione migliore, ma non lo è. Se nel tuo progetto attuale non sei troppo interessato al design e alle opzioni tecniche sopra descritte, o hai solo bisogno di un sito Web operativo che faccia il lavoro oggi, probabilmente non avrai bisogno di headless così tanto.

Naturalmente, la velocità dall'ideazione alla consegna è importante, quindi poiché sei a pochi clic da un sito Web dall'aspetto decente senza un adeguato supporto tecnico dalla tua parte, potresti voler rimandare le opzioni senza testa per un secondo momento. Puoi concentrarti sull'ottimizzazione e sulla longevità del sito quando senti che la tua idea potrebbe funzionare.

In che modo le scelte senza testa ti aiutano a riprenderti dai passi falsi

Aggiornamento del backend

Pericoli del prezzo per utente

Tempo fa, ho aiutato a creare un sistema di blogging che sarebbe stato utilizzato da dozzine di autori. Siamo rimasti molto colpiti dal set di funzionalità di uno dei fornitori di CMS senza testa, l'abbiamo scelto per il CMS senza testa e ci siamo divertiti a creare un frontend su di esso che si integrasse perfettamente nella nostra suite di prodotti. Alla fine, la società decise che il numero degli autori doveva essere ampliato a poche migliaia.

La maggior parte delle soluzioni CMS ospitate non pubblica la struttura dei prezzi per numeri di utenti così grandi. Quando abbiamo chiesto il costo per continuare a farlo funzionare sulla stessa piattaforma, la risposta non ci è piaciuta. Affinché questo sistema continuasse ad avere un senso commerciale, abbiamo dovuto sostituire il nostro CMS. Siamo stati in grado di effettuare lo scambio senza demolire anche il frontend a causa dell'architettura senza testa.

Limitazione dell'API

Così tante startup che si concentrano esclusivamente sull'ambiente di authoring sono in grado di creare bellissimi prodotti con API compatibili con gli sviluppatori. Airtable è un esempio di innovazione del foglio di calcolo attraverso un'interfaccia utente intuitiva combinata con un'esperienza di sviluppo pulita tramite un'API ben documentata.

Ho creato alcuni utili prototipi in cui ho inserito i dati raschiati in Airtable dove sono stati modificati da esperti umani, quindi ho utilizzato le loro API per alimentare le visualizzazioni dei contenuti in esecuzione sul sito principale e negli incorporamenti in esecuzione su siti di terze parti. Durante l'impostazione del sistema di lettura , ho inserito i dati di Airtable in un sistema pronto per la produzione in grado di gestire grandi carichi di traffico e questo ha funzionato bene per un po'.

Tuttavia, ho iniziato a riscontrare problemi con la scrittura dei dati. Le chiamate non andavano a buon fine a causa del limite rigido di 5 richieste al secondo. Il raggiungimento di questo limite comporta un blocco completo delle richieste API di 30 secondi. Stavo tentando di inviare dati da un sistema distribuito, quindi ho aggiunto le limitazioni e diviso le cose in basi separate.

Man mano che il sistema si espandeva e la quantità di dati cresceva, stavamo superando questo strumento. Sono stato in grado di risolvere questo problema creando rudimentali funzionalità di modifica dei dati in un sistema basato sull'istanza AWS DynamoDB che stava leggendo da airtable. Siamo stati in grado di scambiare rapidamente le eleganti funzionalità dell'interfaccia utente di creazione di Airtable con una scala più ampia e fatture SaaS mensili inferiori.

Questo è un altro esempio di come una netta separazione tra front-end e back-end fornita dalle API degli strumenti di authoring headless ti consente di individuare con precisione i punti critici.

Aggiornamento del frontend

Nuovi quadri brillanti

Le organizzazioni che esistono da un po' di tempo spesso hanno il problema di dover supportare sistemi di produzione costruiti su una varietà di stack tecnologici . C'è una pressione costante per omogeneizzare gli utensili ma anche per innovare. Facevo parte di un team incaricato di creare viste e widget che si integrassero nei prodotti esistenti basati su un CMS headless. Ci siamo divertiti molto a costruire rapidamente prototipi con diversi strumenti di frontend leggeri.

Abbiamo condotto un concorso interno per vedere quale ingegnere del team frontend poteva creare il miglior frontend in base al contenuto fornito dagli endpoint dell'API CMS headless. Una presentazione aveva il miglior set di funzionalità e il minimo ingombro di codice, quindi gli sviluppatori hanno ottenuto il progetto e hanno consegnato il prodotto creandolo con Riot.js.

Riot.js è una piccola libreria interessante che racchiude un sacco di funzionalità in dimensioni ridotte. Ti aiuta a scrivere componenti di file singoli basati sui dati come Vue.js. Quando lo sviluppatore di questo frontend ha lasciato l'azienda poco dopo aver distribuito la versione 1.0, il team ha perso l'unica persona con entusiasmo per quella libreria.

A volte la caduta dall'eccitante, nuovo e rapido modello di sviluppo al debito tecnologico avviene rapidamente.

“

Fortunatamente, la natura disaccoppiata dell'architettura CMS headless offre la flessibilità di modificare il front-end senza toccare il back-end . Siamo stati in grado di riscrivere il codice front-end e scambiare componenti front-end aggiornati basati su diverse librerie che erano più comunemente utilizzate in altri progetti.

Velocità grezza

Adoro il progetto Ghost. Sono stato uno dei primi iscritti perché è stato bello vedere una soluzione simile a WordPress basata su Node.js. Rispetto questa organizzazione per offrire un servizio basato su strumenti open source che perfezionano costantemente. Sono stato davvero contento di questo strumento quando l'ho usato per il mio blog personale.

C'era un aspetto della soluzione che però non era perfetto. Il tempo per il primo byte sul mio blog ospitato da Ghost era troppo lento. Dato che potevo recuperare tutto il contenuto del post tramite un'API, sono stato in grado di configurare il mio frontend generato staticamente su S3 + Cloudfront che utilizzava tutto il contenuto del post che avevo scritto in Ghost ma aveva un tempo più veloce per il primo byte.

CMS senza testa come servizio

Ci sono molte aziende di Software As A Service che sono andate all-in senza testa. La registrazione con uno di questi fornitori può offrirti immediatamente un ambiente di modifica dei contenuti intuitivo e endpoint API puliti con cui lavorare. Ecco un rapido confronto tra alcuni di loro, tutti con piani entry-level a basso costo e un focus laser sull'esperienza CMS senza testa.

Tutti questi servizi hanno una solida base di funzionalità . Tutti includono l'hosting di risorse statiche, la cronologia delle revisioni salvata e un supporto per la localizzazione ben documentato. Si differenziano per l'interfaccia utente per la creazione di contenuti e le funzionalità API.

Emozionanti modelli senza testa

Utilizzo di un CMS basato su GitHub

Essere in grado di sfruttare i flussi di lavoro di gestione degli utenti, controllo della versione e approvazione in GitHub sono grandi vantaggi. È utile non dover impostare nuovi account su nuovi sistemi. Poter vedere la cronologia delle recensioni insieme agli aggiornamenti dei contenuti è bello.

Esistono diverse versioni di strumenti CMS basati su GitHub. Questo è stato un modo rapido per creare siti di documentazione: Spacebook puoi integrarlo con Netlify per ottenere un'interfaccia utente di modifica del markdown più pulita o utilizzarlo direttamente su GitHub.

Le funzionalità di anteprima ora integrate nell'editor web di GitHub rendono alcuni di questi strumenti più accessibili alle persone che non hanno familiarità con l'HTML. Adoro l'opzione di differenza ricca di visualizzazione in cui GitHub mostra le modifiche al markdown in modalità di anteprima completa.

Questo è un eccellente elenco di 85 strumenti CMS che ti consentono di ordinare se sono basati su GitHub o meno.

API per strumenti familiari

La tua installazione di WordPress viene fornita con gli endpoint API, quindi puoi continuare a utilizzare gli strumenti di creazione che il tuo team ha sperimentato senza testa. WordPress ha una buona documentazione per la loro API REST. Questo è abilitato sulle nuove installazioni di WordPress, quindi quando crei un nuovo ambiente di creazione di WordPress puoi iniziare a leggere JSON da https://example.com/wp-json/wp/v2/posts .

La pagina delle impostazioni di WordPress contiene un campo del servizio di aggiornamento in cui puoi inserire gli URL per i servizi di cui desideri eseguire il ping quando il contenuto cambia. Questo è perfetto per attivare uno strumento serverless per acquisire gli ultimi aggiornamenti. WordPress v5 ha questo campo nella sezione Scrittura delle impostazioni

Combinazione di origini dati

L'uso di strumenti senza testa per lo stato della California ci ha aiutato a creare siti di risposta alle emergenze che hanno alzato il livello delle prestazioni. Avevamo il pieno controllo dell'architettura front-end ed eravamo ancora in grado di consentire agli autori di utilizzare strumenti di authoring familiari.

Usiamo WordPress senza testa , scrivendo a GitHub tramite FAAS. Stiamo anche scrivendo altre origini dati nel repository e attivando build di generatori di siti statici su ogni modifica. Esempi di dati che vengono scritti su git in aggiunta al contenuto editoriale originale sono dati che cambiano solo una volta al giorno come le statistiche della linea superiore e le nostre versioni tradotte da persone di ogni pagina.

L'utilizzo delle azioni GitHub come trigger di compilazione ci ha consentito di integrare diverse origini dati nel sito in modo da ottenere una pubblicazione rapida e un ingombro ridotto dell'infrastruttura di produzione. Una minore infrastruttura di produzione ci consente di respirare facilmente quando si verificano forti picchi di traffico legati agli annunci di pandemie del governo.

La parte dell'architettura del repository WordPress -> FAAS -> GitHub è stata creata da Carter Medlin. Ha cablato questa pipeline insieme da zero in un paio di giorni mentre progettavamo e costruivamo il frontend del sito. Questo è in esecuzione su una funzione MS Azure serverless, quindi ci sono costi di infrastruttura e manutenzione bassi. Ottiene i ping dal servizio di aggiornamento di WordPress descritto in precedenza, estrae json dall'API di WordPress e scrive nuovi contenuti in GitHub. Il codice per questo endpoint serverless è visualizzabile su GitHub.

I nostri robot sono al lavoro per pubblicare tutti gli aggiornamenti dei contenuti mentre ricevono ping da WordPress. Questa attività crea un registro facilmente consultabile di ogni aggiornamento e la possibilità di ripristinare le modifiche con i normali processi GitHub.

Costruire il frontend di questo sito utilizzando il generatore di siti statici 11ty è stato veloce, divertente e ha funzionato perfettamente. Riceviamo grandi picchi di traffico sulle notizie relative alla pandemia e sapere di avere un frontend statico riduce il rischio quando il conteggio degli utenti simultanei inizia a crescere e stiamo pubblicando molti aggiornamenti dei contenuti.

Mi piace il modo in cui la community di 11ty si concentra sulle prestazioni e sull'accessibilità con le classifiche della community e l'architettura leggera. È importante assicurarsi che gli strumenti costruiti dallo stato funzionino per tutti i californiani. Vogliamo che le cose funzionino su qualsiasi dispositivo in condizioni di larghezza di banda ridotta e supportino tutta la tecnologia assistiva. È piuttosto interessante che possiamo utilizzare strumenti come 11ty che rendono più facile la distribuzione di siti veloci e accessibili. Utilizziamo componenti Web sul frontend per fornire funzionalità aggiuntive mantenendo il peso del codice ridotto.

Considerazioni quando si fanno scelte senza testa

Sei entusiasta delle capacità che gli strumenti senza testa offrono al tuo team? Il numero di opzioni disponibili può essere schiacciante. Questo è un elenco di funzionalità che possono aiutarti a ridurre le opzioni:

Funzionalità dell'ambiente di creazione

• Facilità di creazione di documenti
• Facilità di aggiunta di dati strutturati
• Opzioni di layout
• Funzionalità di anteprima
• Flussi di lavoro di approvazione dei contenuti

Funzionalità dell'API dei contenuti

• Quali query sono disponibili
• Quanto è granulare la struttura del contenuto
• Esistono limitazioni all'accesso ai dati (limiti rigidi dell'API REST di Airtable)
• Scalabilità : hai bisogno di inserire una CDN davanti alla tua API di contenuto
• Facilità di aggiunta della localizzazione
• Far uscire i tuoi contenuti, cosa succede se cambi i tuoi piani, quanto sarà difficile estrarre tutti i tuoi dati?

Costo

• Paghi per utente per soluzioni ospitate?
• Gestisci software open source che installi nel tuo ambiente?
• Gli account utente sono facili da amministrare?
• Potete integrarvi con le vostre soluzioni di single sign-on esistenti?
• Il prodotto ha superato gli audit di sicurezza, include l'autenticazione a due fattori ?

Flussi di controllo/approvazione del codice sorgente

• Il contenuto ha una versione , in modo da poter tornare alle versioni precedenti e tenere traccia di ciò che è stato pubblicato e quali modifiche sono state apportate quando?
• Puoi condividere nuove versioni dei contenuti prima di pubblicarli? Puoi limitare l'accesso a queste anteprime?

Gestione dei file statici

• Quanto è facile per i tuoi autori aggiungere nuove immagini, pdf, ecc.?
• Facilità di agganciare i file caricati dall'autore nei flussi di ottimizzazione delle immagini?

Dove si sta dirigendo senza testa

Se osservi da vicino il panorama senza testa, scoprirai che gli strumenti senza testa limitano intenzionalmente la loro portata funzionale e forniscono modi per integrarsi in sistemi più grandi. La disaggregazione di funzionalità specifiche è utile quando i sistemi diventano più complessi. È solo più facile fare scelte specifiche che limitino i costi, la sicurezza, la manutenzione e i requisiti di hosting di footprint di codice più grandi quando lavori con strumenti più piccoli e mirati.

Vale la pena notare che le opzioni senza testa di solito richiedono la scrittura del codice da soli. Tuttavia, poiché i frontend sono sempre più un insieme di componenti predefiniti e spesso un intero progetto pronto all'uso riempito con i tuoi dati, non dovrebbe essere troppo presuntuoso aspettarsi più modi per combinare e abbinare strumenti specializzati e integrarsi perfettamente opzioni senza testa senza scrivere il codice da soli.

Il backend perfetto per un progetto potrebbe essere solo un abbonamento SAAS o un progetto open source installato. Questo può integrarsi senza codice con un frontend pronto all'uso che soddisfa tutte le tue esigenze. Vedo che Stackbit sta già fondendo CMS senza testa con il loro frontend senza codice. Posso creare un nuovo sito utilizzando lo strumento WYSIWYG senza codepage di Stackbit e quindi posso scegliere da una serie di opzioni CMS senza testa di diversi fornitori per gestire i dati completi del sito.

In questo articolo, abbiamo esaminato alcuni casi d'uso in cui andare senza testa ha aiutato le aziende per cui ho lavorato a far fronte al cambiamento. Le scelte senza testa sono allettanti sia che tu ne sia interessato per la flessibilità dell'architettura dell'applicazione, il controllo dell'esperienza utente o per riflettere attentamente sulla longevità del tuo servizio.

Sono entusiasta di vedere come questo spazio continua a crescere e continuerò a cercare modi per utilizzare queste opzioni per fornire prodotti migliori e semplificare il mio lavoro di sviluppatore.

Ulteriori risorse

• CMS senza testa, un eccellente elenco di 85 strumenti CMS che ti consente di ordinare se sono basati su GitHub o meno.
• "Come creare un sito WordPress senza testa su Jamstack", Sarah Drasner e Geoff Graham
• Commercio senza testa, Shopify
• "GoTrue JS: portare l'autenticazione su siti statici con solo 3kb di JS", Divya Sasidharan, Netlify
• L'esperienza di editing per i siti Jamstack, Stackbit
• API di integrazione di Wordpress, CAdotGov, GitHub

Questo articolo è stato gentilmente supportato dai nostri cari amici di Storyblok, un simpatico CMS headless con un editor visivo, componenti nidificati e blocchi di contenuto personalizzabili per siti Web e app. Grazie!