A deveni fără cap: cazuri de utilizare și la ce este bun

Acest articol a fost susținut cu amabilitate de dragii noștri prieteni de la Storyblok, un CMS prietenos fără cap, cu un editor vizual, componente imbricate și blocuri de conținut personalizabile pentru site-uri web și aplicații. Mulțumesc!

Privind înapoi la anii de dezvoltare pentru web, am folosit zeci de instrumente CMS diferite, atât de pe raft, cât și produse în casă. Am implementat și construit o mulțime de site-uri și plugin-uri WordPress , precum și extensii pentru site-uri CMS cu servicii complete în .NET. Dar pentru mine, totul s-a schimbat când am auzit prima dată de fără cap, iar acum, ani mai târziu, nu m-aș putea simți mai confortabil în ecosistemul fără cap .

Acest entuziasm nu vine de nicăieri. Deși ar putea părea descurajant să dau sens tuturor opțiunilor fără cap, mi-am perfecționat propria strategie pentru diferite opțiuni fără cap în diferite medii și m-am familiarizat îndeaproape cu suspecții obișnuiți din spațiul fără cap. Trecerea la headless m-a ajutat să evit să intru în blocaje cauzate de limitările sistemelor all-in-one mai mari.

Compartimentarea funcționalității, astfel încât să puteți îndeplini obiective complexe astăzi și să vă pregătiți aplicația pentru a evolua cu ușurință în viitor, îmi aduce liniște sufletească. A fost o plăcere să contribui la implementări și iterații de succes pe servicii web construite pe soluții headless pentru companii private și guvernul statului California.

În acest articol, mi-ar plăcea să vă împărtășesc câteva dintre indicațiile și liniile directoare utile pe care le-am învățat de-a lungul acestor ani, cu speranța că vă vor ajuta să înțelegeți lumea fără cap și să găsiți candidații potriviți pentru proiectele dvs. Dar înainte de a ne scufunda, trebuie să ne întoarcem puțin în timp pentru a înțelege ce aduce fără cap la masă.

Înainte de Headless

Cu doar câțiva ani în urmă, fluxurile noastre de lucru păreau să se concentreze pe o gamă largă de instrumente, stive și tehnologii. Pentru CMS, folosim în mare parte instrumente all-in-one. Acestea au inclus atât funcțiile de creare a conținutului, cât și de vizualizare a conținutului.

Utilizatorii acestor instrumente au rămas blocați cu front-end -ul livrat cu backend-ul. Capacitatea ta de a personaliza lucrurile a fost limitată. Ai putea instala pluginuri, dar toate trebuiau construite pentru instrumentul tău. Puteți scrie cod personalizat - dar numai în limba în care este construit instrumentul dvs. și în limitele sale.

Totul s-a schimbat în ultimii ani, CMS-ul fără cap care a câștigat acțiune în întreaga industrie.

O renaștere a instrumentelor specializate

Astăzi, avem o mulțime de instrumente specializate fie în vizualizări de creație, fie în prezentarea conținutului. Un CMS fără cap se concentrează asupra piesei de creație a conținutului și oferă o modalitate de a conecta un instrument separat de prezentare a conținutului. Lipsa unui frontend orientat spre utilizator este ceea ce îl face fără cap și îi oferă flexibilitatea de a lucra cu orice instrument prin intermediul API-ului său.

A fi capabil să-ți proiectezi propriul frontend de la zero este eliberator pentru multe echipe de dezvoltare. Este posibil să aveți o echipă excelentă de ingineri care să livreze fluent aplicații elegante cu o singură pagină în Vue.js sau cu randare rapidă, site-uri static generate cu 11ty. Toate cele mai recente cadre de dezvoltare web sunt concepute pentru a funcționa cu ușurință cu date structurate care pot fi furnizate de la orice CMS fără cap.

Un CMS fără cap este un instrument concentrat. Are mai puțină responsabilitate decât o soluție all-in-one. Punctele finale API furnizate de un CMS fără cap oferă o separare clară între sisteme, astfel încât să puteți schimba arhitecturile front sau backend independent, pe măsură ce lucrurile evoluează. Produsul tău crește, ecosistemul de instrumente se extinde, noi abordări devin disponibile. Cerințele dvs. de backend și frontend se vor schimba. Dacă aveți o configurație fără cap, vă veți putea adapta mai ușor, deoarece frontul și backend-ul sunt deja separate clar de un API și le puteți actualiza independent.

Este fără cap potrivit pentru mine?

Cel mai important, headless vă oferă flexibilitatea de care aveți nevoie pentru a îndeplini cerințele provocatoare. Ar putea fi dificil să vă îndepliniți obiectivele dacă trebuie să modificați puternic un produs all-in-one. Combinarea unui instrument fără cap cu o interfață mai mică, diferită sau homebrewed ar putea fi cea mai ușoară modalitate de a livra design-urile și fluxurile de utilizatori dorite.

• Dacă doriți să reglați fiecare pas al fluxului de achiziție a produsului , puteți utiliza o opțiune de comerț fără cap pentru a realiza acest lucru,
• Dacă doriți să optimizați puternic pentru Time to First Byte , este posibil să doriți să utilizați un generator de site static care reconstruiește conținutul pe baza modificărilor pe baza unui API CMS fără cap,
• Dacă vă găzduiți propriile instrumente și sunteți precaut în ceea ce privește securitatea, este posibil să doriți să blocați mediul dvs. de creație în spatele firewall-ului și să-l consumați fără cap dintr-un frontend mai simplu bazat pe Jamstack,
• Dacă difuzați același conținut către o varietate de clienți, cum ar fi web, aplicații native sau widget-uri terță parte, le puteți crea într-un mod în care toți ar comunica prin același CMS fără cap.

Dacă puteți îndeplini perfect cerințele proiectului dvs. cu un instrument all-in-one, atunci opțiunile fără cap sunt probabil puțin exagerate pentru dvs. În același mod, dacă echipa ta este perfect mulțumită și familiarizată cu soluția actuală all-in-one, nu trebuie să-ți faci griji cu privire la împărțirea instrumentelor frontale și backend. Cu toate acestea, dacă, în schimb, vă confruntați cu limitările instrumentelor dvs., atunci să faceți fără cap vă va permite să vă abordați direct punctele dureroase.

Exemplu: comerț electronic fără cap

Să ne uităm la o anumită alegere fără cap: puteți integra o platformă de comerț electronic existentă, cum ar fi Shopify, ca un flux complet care preia întregul proces de plată sau puteți utiliza o opțiune fără cap pe care o oferă Shopify.

• În primul caz, designul dvs. se va baza în mare măsură pe șabloanele Shopify și pe funcționalitatea ieșită din cutie , astfel încât ajustarea fluxului de plată va fi posibilă, dar destul de limitată.
• În acest din urmă caz, vă puteți proiecta fluxul de plată în orice mod doriți și vă veți baza pe Shopify pentru a efectua doar tranzacția financiară.

Diferența semnificativă este că opțiunea fără cap va cere să construiți fiecare vizualizare pe care o vede utilizatorul dvs. Din nou, dacă sună ca o bătaie de cap fără avantaj, atunci probabil că nu aveți nevoie de o soluție fără cap.

O echipă care are nevoie de versiunea fără cap va saluta libertatea pe care aceasta o oferă. Designul dvs. nu va avea constrângeri și veți putea controla fiecare pixel din fiecare vizualizare. Veți avea control total asupra întregului cod care se execută pe dispozitivele utilizatorului, astfel încât să puteți urmări, optimiza și accelera literalmente fiecare interacțiune.

În același timp, lăsați în continuare procesarea tranzacțiilor soluției dvs. de comerț electronic fără cap, astfel încât beneficiați de avantajele sistemului lor de backend.

Concluzia este: dacă vă confruntați cu blocajele din soluția dvs. actuală de comerț electronic – fie că este vorba de front-end greu, de interfață de utilizare complexă sau doar de design inaccesibil – atunci o opțiune fără cap va facilita pentru echipa dumneavoastră să rezolve aceste probleme. În mod similar, dacă se pare că va face mai ușor pentru echipa dvs. să vă sporească pâlnia de conversie, făcând implementarea noilor funcții mai rapidă și mai lină, atunci este o idee bună să luați în considerare și opțiunea fără cap.

Evitarea blocării cu o singură platformă

Privind starea front-end-ului de azi, decuplarea vehiculelor dvs. de creație și livrare de conținut este cea mai sigură modalitate de a proiecta lucrurile într-o lume în care opțiunile pentru instrumentele de front și backend sunt în continuă extindere. Nu este neobișnuit ca mediile de creație și de citire să aibă seturi diferite de cerințe, așa că posibilitatea de a alege instrumente care le abordează separat vă oferă opțiuni mai bune pentru ambele părți.

Configurațiile bazate pe Jamstack sunt activate de API-uri, așa că sunt adesea legate de un CMS fără cap. A face o alegere fără cap nu necesită totuși un front-end Jamstack . Desigur, ai putea încă rula un cod de pe server dacă vrei.

De exemplu, am contribuit la construirea unor site-uri care rulează Node.js și Express care consumă API-uri back-end precum Wordnik.com și acest model popular funcționează fără probleme. Accesul la datele dvs. prin intermediul API-urilor face posibilă renunțarea la codul dvs. de pe partea serverului în producție, astfel încât să puteți adopta cu ușurință abordări la nivelul clientului, cum ar fi Jamstack, dacă acest lucru are sens în proiectul dvs.

Problema cu soluțiile „all-in-one” este că fiecare dintre ele are o mulțime de angajamente incluse. De exemplu, trebuie să vă angajați să susțineți o bază de date și un mediu de programare sau să alegeți dintre furnizorii SaaS care o fac; de asemenea, modificările de design vor trebui să apară în temele și pluginurile disponibile.

Cu fără cap, ieșim de la blocarea pe o singură platformă. Deci, dacă trebuie să utilizați un nou cadru front-end pentru site-ul dvs. sau doriți să eliminați infrastructura de producție costisitoare și să utilizați generatoare statice de site, sau poate doriți să vă schimbați CMS-ul fără a vă reconstrui întregul front-end de la zero - în comparație cu alternativele , puteți obține toate acestea cu mult mai puțină frecare atunci când utilizați o opțiune fără cap.

Să aruncăm o privire la un exemplu simplu. Imaginați-vă că organizația dvs. vine cu o nouă inițiativă și un nou design, iar fluxurile sunt create de la zero pentru a satisface noile nevoi ale utilizatorilor. Dintr-o dată, o nouă stivă de tehnologie trebuie să fie asamblată pentru a îndeplini aceste cerințe.

Alegerea unei opțiuni fără cap va oferi produselor tale o șansă mai bună de longevitate și va face mult mai ușor să permiteți conținutului să se deplaseze fără probleme în mai multe canale de livrare.

„

În astfel de cazuri, va trebui să căutați o soluție disponibilă perfectă, care să se potrivească perfect nevoilor dvs. sau să compromiteți unele dintre cerințele de design și fluxul de utilizator, astfel încât să funcționeze suficient de bine. Dar dacă cerințele dvs. de design sau de performanță sunt stricte, poate fi mai ușor să vă îndepliniți aceste obiective dacă nu aveți cap.

Concluzia este că există o mulțime de cazuri de utilizare atunci când alegeți o opțiune fără cap, care va oferi produselor dvs. o șansă mai bună de longevitate și va face mult mai ușor să vă permiteți conținutului să se deplaseze fără probleme în mai multe canale de livrare. Capacitatea de a consuma conținutul dvs. ca date structurate îi permite să prospere pe propriul dvs. site web, în ​​aplicațiile dvs. native și să fie sindicalizat către surse externe.

Nu totul trebuie să fie fără cap

S-ar putea să sune că fără cap este întotdeauna o opțiune mai bună, dar nu este. Dacă în proiectul dvs. actual nu sunteți prea preocupat de opțiunile de design și tehnice descrise mai sus, sau aveți nevoie doar de un site web operațional care să facă treaba astăzi, atunci probabil că nu veți avea nevoie de atât de mult headless.

Desigur, viteza de la concept până la livrare este importantă, așa că, deoarece vă aflați la câteva clicuri distanță de un site web cu aspect decent, fără asistență tehnică adecvată din partea dvs., este posibil să doriți să amânați opțiunile fără cap pentru o dată ulterioară. Vă puteți concentra pe optimizarea site-ului și pe longevitate odată ce simțiți că ideea dvs. ar putea funcționa.

Cum vă ajută alegerile fără cap să vă recuperați din pași greșiți

Actualizarea backend-ului

Pericolele prețurilor pe utilizator

Cu ceva timp în urmă, am ajutat la crearea unui sistem de blogging care să fie folosit de zeci de autori. Am fost foarte impresionați de setul de caracteristici al unuia dintre furnizorii de CMS fără cap, l-am ales pentru CMS fără cap și ne-a plăcut să construim un front-end deasupra acestuia care s-a îmbinat fără probleme în suita noastră de produse. În cele din urmă, compania a decis ca numărul de autori să fie extins la câteva mii.

Majoritatea soluțiilor CMS găzduite nu publică structura prețurilor pentru numerele de utilizatori atât de mari. Când am întrebat despre costul continuării rulării pe aceeași platformă, nu ne-a plăcut răspunsul. Pentru ca acest sistem să continue să aibă sens în afaceri, a trebuit să schimbăm CMS-ul nostru. Am reușit să facem schimbul fără a casa și front-end-ul datorită arhitecturii fără cap.

Reglare API

Atât de multe startup-uri care se concentrează exclusiv pe mediul de creație sunt capabile să construiască produse frumoase cu API-uri prietenoase pentru dezvoltatori. Airtable este un exemplu de inovație în foile de calcul prin intermediul unei interfețe de utilizare ușor de utilizat, combinată cu o experiență curată a dezvoltatorului printr-un API bine documentat.

Am construit câteva prototipuri utile în care am introdus date răzuite în Airtable, unde au fost editate de experți umani, apoi le-am folosit API-urile pentru a alimenta vizualizările de conținut care rulează pe site-ul principal și în incorporări care rulează pe site-uri terțe. Când am configurat sistemul de citire , am extras datele Airtable într-un sistem pregătit pentru producție, care putea face față unor sarcini mari de trafic și acest lucru a funcționat bine pentru o perioadă.

Totuși, am început să întâmpin probleme cu scrierea datelor. Apelurile au eșuat din cauza limitei stricte de 5 solicitări pe secundă. Atingerea acestei limite oferă o blocare completă a solicitării API de 30 de secunde. Încercam să trimit date dintr-un sistem distribuit, așa că am adăugat accelerații și am împărțit lucrurile în baze separate.

Pe măsură ce sistemul sa extins și cantitatea de date a crescut, am depășit acest instrument. Am reușit să rezolv acest lucru prin construirea unor funcții rudimentare de editare a datelor într-un sistem bazat pe instanța AWS DynamoDB care a citit din airtable. Am reușit să schimbăm rapid caracteristicile UI de creație ale Airtable pentru o scară mai mare și facturi lunare SaaS mai mici.

Acesta este un alt exemplu al modului în care o separare clară între front-end și backend oferită de API-urile instrumentelor de creație fără headless vă permite să vizați cu precizie punctele dure.

Actualizarea Frontend-ului

Cadre noi strălucitoare

Organizațiile care există de ceva vreme au adesea problema de a avea nevoie să susțină sisteme de producție construite pe o varietate de stive tehnologice . Există o presiune constantă pentru omogenizarea sculelor, dar și pentru inovare. Am făcut parte dintr-o echipă însărcinată cu crearea de vizualizări și widget-uri care să se integreze în produsele existente bazate pe un CMS fără cap. Ne-am distrat foarte mult construind rapid prototipuri cu diferite instrumente frontale ușoare.

Am desfășurat un concurs intern pentru a vedea care inginer din echipa de front-end ar putea crea cel mai bun frontend pe baza conținutului livrat de la punctele finale API CMS fără cap. O prezentare a avut cel mai bun set de caracteristici și cea mai mică amprentă de cod, astfel încât dezvoltatorii au preluat proiectul și au livrat produsul creându-l cu Riot.js.

Riot.js este o mică bibliotecă grozavă care include o mulțime de funcții într-o dimensiune mică. Vă ajută să scrieți componente de fișier unic bazate pe date, cum ar fi Vue.js. Când dezvoltatorul acestui frontend a părăsit compania la scurt timp după livrarea versiunii 1.0, echipa a pierdut singura persoană cu entuziasm pentru acea bibliotecă.

Uneori, trecerea de la un model de dezvoltare interesant, nou și rapid la datoria tehnologică are loc rapid.

„

Din fericire, natura decuplată a arhitecturii CMS fără cap oferă flexibilitatea de a vă schimba front-end-ul fără a atinge backend-ul . Am reușit să rescriem codul front-end și să schimbăm componentele front-end actualizate pe baza diferitelor biblioteci care au fost utilizate mai frecvent în alte proiecte.

Viteza brută

Îmi place proiectul Ghost. Am fost un abonat timpuriu pentru că a fost cool să văd o soluție asemănătoare WordPress construită pe Node.js. Respect această organizație pentru că oferă un serviciu construit pe instrumente open source pe care le rafinează în mod constant. Am fost foarte mulțumit de acest instrument când l-am folosit pentru blogul meu personal.

A existat o fațetă a soluției care nu era perfectă. Timpul până la primul octet pe blogul meu găzduit de Ghost a fost prea lent. Deoarece am putut prelua tot conținutul postării printr-un API, am putut să îmi configurez propriul frontend generat static pe S3 + Cloudfront, care a folosit tot conținutul postării pe care l-am scris în Ghost, dar a avut un timp mai rapid la primul octet.

CMS fără cap ca serviciu

Există multe companii Software As A Service care au făcut all-in- ul fără cap. Înregistrarea la unul dintre acești furnizori vă poate oferi imediat un mediu prietenos de editare a conținutului și puncte finale API curate cu care să lucrați. Iată o comparație rapidă a câtorva dintre aceștia, care au, toți, planuri de nivel de intrare cu costuri foarte mici și o concentrare laser pe experiența CMS fără cap.

Toate aceste servicii au o bază solidă de caracteristici . Toate includ găzduirea statică a activelor, istoricul de revizii salvat și suport de localizare bine documentat. Ele diferă în ceea ce privește interfața de utilizator pentru crearea de conținut și funcțiile API.

Modele interesante fără cap

Utilizarea unui CMS bazat pe GitHub

Posibilitatea de a profita de gestionarea utilizatorilor, controlul versiunilor și fluxurile de lucru de aprobare în GitHub sunt mari avantaje. Este util să nu trebuiască să creați conturi noi pe sisteme noi. Este plăcut să poți vedea istoricul recenziilor alături de actualizările de conținut.

Există diferite variante de instrumente CMS bazate pe GitHub. Acesta a fost o modalitate rapidă de a crea site-uri de documentare: Spacebook, îl puteți integra cu Netlify pentru a obține o interfață de utilizare mai curată de editare a reducerilor sau o puteți utiliza direct pe GitHub.

Funcțiile de previzualizare care sunt acum încorporate în editorul web GitHub fac unele dintre aceste instrumente mai accesibile persoanelor care nu sunt familiarizate cu HTML. Îmi place opțiunea de diferență bogată în vizualizare, în care GitHub arată modificările de reducere în modul de previzualizare completă.

Aceasta este o listă excelentă de 85 de instrumente CMS care vă permite să sortați dacă sunt bazate pe GitHub sau nu.

API-uri pentru instrumente familiare

Instalarea dvs. WordPress vine cu puncte finale API, astfel încât să puteți continua să utilizați instrumente de creație pe care echipa dvs. are experiență fără cap. WordPress are o documentație bună pentru API-ul REST. Acest lucru este activat pentru noile instalări WordPress, așa că atunci când porniți un nou mediu de creație WordPress puteți începe să citiți JSON de la https://example.com/wp-json/wp/v2/posts .

Pagina de setări WordPress conține un câmp de serviciu de actualizare în care puteți introduce adrese URL pentru serviciile pe care doriți să le facă ping atunci când conținutul se modifică. Acest lucru este perfect pentru a declanșa un instrument fără server pentru a obține cele mai recente actualizări. WordPress v5 are acest câmp în secțiunea Scriere din setări

Combinarea surselor de date

Folosirea instrumentelor fără cap pentru statul California ne-a ajutat să creăm site-uri de răspuns în situații de urgență care au ridicat ștacheta performanței. Am avut control deplin asupra arhitecturii frontend și am putut în continuare să permitem scriitorilor să folosească instrumente de autor familiare.

Folosim WordPress fără cap , scriind la GitHub prin FAAS. De asemenea, scriem și alte surse de date în depozit și declanșăm generatorul de site-uri static pe baza fiecărei modificări. Exemple de date care sunt scrise în git în plus față de conținutul editorial original sunt date care se modifică doar o dată pe zi, cum ar fi statisticile de top și versiunile noastre traduse de către oameni ale fiecărei pagini.

Folosirea acțiunilor GitHub ca declanșatori de compilare ne-a permis să integrăm mai multe surse de date diferite în site, astfel încât să obținem o publicare rapidă și o amprentă mică a infrastructurii de producție. Mai puțină infrastructură de producție ne permite să respirăm ușor atunci când atingem vârfuri mari de trafic legate de anunțurile guvernamentale privind pandemia.

Partea WordPress -> FAAS -> GitHub repo a arhitecturii a fost creată de Carter Medlin. El a conectat această conductă de la zero în câteva zile, în timp ce noi proiectam și construiam interfața site-ului. Acesta rulează pe o funcție MS Azure fără server, astfel încât există costuri reduse de infrastructură și întreținere. Primește ping-uri de la serviciul de actualizare WordPress descris mai devreme, extrage json din API-ul WordPress și scrie conținut nou în GitHub. Codul pentru acest punct final fără server este vizibil pe GitHub.

Boții din afara lucrează din greu pentru a publica toate actualizările de conținut , deoarece primesc ping-uri de la WordPress. Această activitate creează un jurnal ușor de revizuit al fiecărei actualizări și abilitatea de a anula modificările cu procesele obișnuite GitHub.

Construirea front-end-ului acestui site folosind generatorul de site static 11ty a fost rapidă, distractivă și a funcționat perfect. Înregistrăm creșteri mari de trafic pe știrile legate de pandemie și știind că avem un front-end static reduce riscul atunci când numărul utilizatorilor concurenți începe să crească și publicăm o mulțime de actualizări de conținut.

Îmi place cum se concentrează comunitatea 11ty pe performanță și accesibilitate cu clasamentele comunității și arhitectura ușoară. Este important să ne asigurăm că instrumentele construite de stat funcționează pentru toți californienii. Ne dorim ca lucrurile să funcționeze pe orice dispozitiv în condiții de lățime de bandă redusă și să accepte toate tehnologiile de asistență. Este destul de grozav că putem folosi instrumente precum 11ty care facilitează livrarea site-urilor rapide și accesibile. Folosim componente web pe front-end pentru a oferi funcții suplimentare, păstrând în același timp greutatea codului mică.

Considerații atunci când faceți alegeri fără cap

Ești încântat de capacitățile oferite de instrumentele fără cap echipei tale? Numărul de opțiuni disponibile poate fi copleșitor. Aceasta este o listă de caracteristici care vă pot ajuta să reduceți opțiunile:

Caracteristici ale mediului de creație

• Ușurință în crearea documentelor
• Ușurință în adăugarea datelor structurate
• Opțiuni de aspect
• Previzualizare caracteristici
• Fluxuri de lucru pentru aprobarea conținutului

Caracteristici API de conținut

• Ce întrebări sunt disponibile
• Cât de granulară este structura conținutului
• Există limitări privind accesul la date (limite stricte ale API-ului Airtable REST)
• Scalabilitate : trebuie să puneți un CDN în fața API-ului dvs. de conținut
• Ușurință în adăugarea localizării
• Scoaterea conținutului, ce se întâmplă dacă îți schimbi planurile, cât de greu va fi extragerea tuturor datelor?

Cost

• Plătiți per utilizator pentru soluții găzduite?
• Gestionați software-ul open source pe care îl instalați în propriul mediu?
• Sunt conturile de utilizator ușor de administrat?
• Vă puteți integra cu soluțiile dvs. de conectare unică existente?
• Produsul a trecut auditurile de securitate, include autentificarea cu doi factori ?

Fluxuri de control/aprobare sursă

• Conținutul are versiuni , astfel încât să puteți reveni la versiunile anterioare și să urmăriți ceea ce a fost publicat și ce modificări au fost făcute când?
• Puteți partaja versiuni noi de conținut înainte de a le publica? Puteți restricționa accesul la aceste previzualizări?

Gestionarea fișierelor statice

• Cât de ușor este pentru autorii tăi să adauge noi imagini, pdf-uri etc.?
• Ușurința de a conecta fișierele încărcate de autor în fluxurile de optimizare a imaginii?

Unde se îndreaptă fără cap

Când te uiți îndeaproape în peisajul fără cap, vei descoperi că instrumentele fără cap își limitează în mod intenționat domeniul de aplicare și oferă modalități de integrare în sisteme mai mari. Separarea caracteristicilor specifice este benefică atunci când sistemele devin mai complexe. Este mai ușor să faceți alegeri specifice care limitează costurile, securitatea, întreținerea, cerințele de găzduire ale unor amprente mai mari de cod atunci când lucrați cu instrumente mai mici și concentrate.

Este demn de remarcat faptul că opțiunile fără cap necesită, de obicei, să scrieți singur un cod . Cu toate acestea, deoarece front-end-urile sunt din ce în ce mai mult un set de componente prefabricate și adesea un întreg design complet complet cu propriile dvs. date, nu ar trebui să fie prea presumptuos să vă așteptați la mai multe modalități de a combina instrumente specializate și de a integra perfect. opțiuni fără cap fără a scrie codul singur.

Backend-ul perfect pentru un proiect ar putea fi doar un abonament SAAS sau un proiect open-source instalat departe. Acest lucru se poate integra fără cod cu o interfață standard care răspunde tuturor nevoilor dvs. Văd că Stackbit îmbină deja CMS fără cap cu frontend-ul lor fără cod. Pot configura un nou site folosind instrumentul de creare a paginii de cod WYSIWYG de la Stackbit și apoi pot alege dintr-un set de opțiuni CMS fără cap de la diferiți furnizori pentru a gestiona datele complete ale site-ului.

În acest articol, am trecut peste câteva cazuri de utilizare în care a depăși capul a ajutat companiile pentru care am lucrat să facă față schimbării. Alegerile fără cap sunt atrăgătoare, indiferent dacă sunteți interesat de ele pentru flexibilitatea arhitecturii aplicației, controlul experienței utilizatorului sau să vă gândiți cu atenție la longevitatea serviciului dumneavoastră.

Sunt încântat să văd cum acest spațiu continuă să crească și voi continua să caut modalități de a folosi aceste opțiuni pentru a oferi produse mai bune și pentru a-mi ușura munca de dezvoltator.

Resurse suplimentare

• Headless CMS, o listă excelentă de 85 de instrumente CMS care vă permite să sortați dacă sunt bazate pe GitHub sau nu.
• „Cum să creezi un site WordPress fără cap pe Jamstack”, Sarah Drasner și Geoff Graham
• Headless Commerce, Shopify
• „GoTrue JS: Aducerea autentificării site-urilor statice cu doar 3 kb de JS”, ​​Divya Sasidharan, Netlify
• Experiența de editare pentru site-urile Jamstack, Stackbit
• API de integrare Wordpress, CAdotGov, GitHub

Acest articol a fost susținut cu amabilitate de dragii noștri prieteni de la Storyblok, un CMS prietenos fără cap, cu un editor vizual, componente imbricate și blocuri de conținut personalizabile pentru site-uri web și aplicații. Mulțumesc!