Cum să alegi un CMS fără cap
Publicat: 2022-03-10Acest 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!
Paginile web, cum ar fi cea pe care o citiți acum, au text, imagini, videoclipuri și alte materiale pentru a vă aduce informații. Aceste date vor fi adunate și create într-un Web Content Management System (WCMS) de către un editor de conținut. WCMS-urile au trecut printr-o evoluție, trecând de la un CMS tradițional la un CMS decuplat la un CMS fără cap.
Trecerea la un CMS fără cap nu este o decizie ușoară și procesul de selecție nu trebuie luat cu ușurință. În acest articol, voi evidenția câteva caracteristici de bază pe care fiecare CMS fără cap ar trebui să le ofere . Vom explora aceste caracteristici, provocările asociate și vă vom ajuta să alegeți un CMS fără cap pentru a satisface cerințele unice ale organizației dumneavoastră.
În calitate de director tehnic la Luminary, am ajutat clienții noștri să aleagă cel mai bun CMS, DXP (Digital Experience Platform) sau CMS fără cap pentru a se potrivi nevoilor lor. Cu cei 21 de ani de experiență ai Luminary în spațiul digital, experiența mea de 17 ani în spațiul CMS, precum și concentrarea noastră pe Headless din 2016, iată cei doi cenți ai mei la ceea ce ar trebui să ai grijă.
Lucruri de luat în considerare atunci când alegeți un CMS fără cap
- Concepte
- Arhitectura microservicii
- Omnicanal
- Pentru autorii de conținut
- Experiență de editare
- Gestionarea imaginilor
- Roluri de autor
- Fluxuri de lucru
- Previzualizarea conținutului
- Localizarea conținutului
- Pentru dezvoltatori
- API-urile RESTful și GraphQL
- SDK-uri native
- Medii
- CDN-uri
- Limite de utilizare
- Alti factori
- Locațiile centrelor de date
- Suport tehnic si vanzari
- Caracteristici Enterprise
- Integrarea infrastructurii
- Furnizori SaaS renumiți
- Integrarea CMS fără cap ca microserviciu
- Cele mai bune servicii de rase
- Canalele pe care doriți să le vizați
- Bune practici de modelare a conținutului
- Experiență de autor
- Structura elementelor de conținut
- Ușurință în căutarea conținutului
- Folosirea excesivă a editorilor WYSIWYG
- Reutilizarea conținutului
- Organizarea imaginilor
- Decuparea și livrarea imaginilor printr-un CDN
- Cele mai bune servicii video externe
- Roluri distincte
- Numărul de utilizatori back-office
- Fluxuri de lucru robuste
- Webhook-uri
- Previzualizează API-urile de la furnizor
- Separați mediile de punere în scenă și de producție din partea dvs
- Suport pentru internaționalizare și localizare
- Crearea propriului plan pentru gestionarea localităților
- API-uri REST mature
- Suport GraphQL
- Previzualizează și securizează API-urile
- API-uri de gestionare a conținutului pentru operațiunile CRUD
- Încercări gratuite pentru a-l încerca
- Un SDK acceptat pentru alegerea dvs. de tehnologie, limbă și platformă.
- Medii din CMS-ul tău fără cap
- Abilitatea de a porta conținut între medii
- Memorarea în cache a imaginilor și a conținutului prin CDN
- Capabilitati de domeniu personalizate
- Limite asupra anumitor caracteristici
- Cheltuieli de funcționare
- Cerințe legale și de reglementare pentru stocarea datelor
- Vânzări locale și suport tehnic
- Funcții de întreprindere fără de care nu poți trăi
- Implicarea comunității cu vânzătorul și cu produsul
- Asistență pentru alegerea dvs. de infrastructură
- A deveni fără cap: cazuri de utilizare și la ce este bun
- Nu vă pierdeți capul: evaluarea fără cap
Monolitic vs Microservicii
Am explorat în detaliu conceptele din spatele CMS-urilor fără cap, aici pe Smashing Magazine, dar haideți să facem o recapitulare rapidă. Când vine vorba de un CMS tradițional, CMS-ul și site-ul web front-end rezultat sunt construite pe o arhitectură monolitică. CMS-ul tradițional încearcă și reușește în multe feluri să servească nevoilor dezvoltatorului, autorului de conținut și marketerului. De exemplu, dacă CMS-ul este construit pe Microsoft .NET Framework, site-ul web front-end ar fi, de asemenea, construit pe aceeași tehnologie. Toate funcționalitățile și integrările ar avea, de asemenea, o dependență strânsă care, la rândul său, are ca rezultat o bază de cod monolitică mare și greoaie.
CMS-urile decuplate au eliminat această interdependență într-o anumită măsură. Acest lucru a fost realizat prin separarea site-ului web front-end de back-office-ul CMS și de depozitul de conținut.
Arhitectura monolitică ocupă un ban din spate cu CMS-uri fără cap. CMS-ul și orice altă integrare este un microserviciu. CMS-ul în sine este furnizat pe un model Software-as-a-Service (SaaS) pe care îmi place să-l numesc Content-as-as-Service (CaaS). Cu această arhitectură de microservicii, tot ceea ce obțineți de la CMS-ul dvs. tradițional nu iese din cutie. Este posibil să aveți diferiți servicii și furnizori pentru a vă oferi cele mai bune produse pentru fiecare dintre cerințele dvs.
Trecerea la o mentalitate de microservicii necesită puțină răbdare. Am avut specialiști în marketing dintr-un mediu CMS tradițional care au rezistat ideii de a explora mai multe sisteme și servicii atunci când folosesc un CMS fără cap. Am reușit să-i ducem în călătorie în timpul selecției și implementării platformei lor CMS fără cap. Acum, ei sunt susținători ai acelei platforme CMS fără cap, deoarece le permite să integreze noi sisteme și servicii, mai degrabă decât să fie legați de unul furnizat de un CMS tradițional.
Ai grijă la:
Omnicanal în centrul său
Oricât de mult te-ar ajuta o mentalitate de microservicii atunci când integrezi un CMS fără head, adevărata putere a headless este realizată în natura sa omnicanal. O experiență omnicanal se învârte în jurul clientului dvs. și creează o experiență unică pentru client în cadrul mărcii dvs. prin unificarea vânzărilor și marketingului. Cu un CMS fără cap, conținutul este furnizat către diferite canale, cum ar fi web, mobil, social, dispozitive inteligente fără UI, dispozitive IoT și chiar puncte de contact non-digitale, cum ar fi o vitrină fizică.
Cu un CMS fără cap, trebuie să definiți schema pentru fiecare model de conținut de la zero . Procesul de definire a acestei structuri de taxonomie logică și solidă pentru elementele de conținut pe care le creați și publicați este cunoscut sub denumirea de modelare a conținutului. Dacă primul tău canal va fi site-ul tău web, asigură-te că modelarea conținutului tău ia în considerare omnicanalul pentru a atenua orice durere viitoare. Dacă căutați doar un CMS de înlocuire pentru a vă alimenta site-ul, aruncați o altă privire asupra spațiului CMS tradițional sau decuplat pentru a vedea dacă există ceva care s-ar potrivi mai bine cerințelor dvs.
Când modelați scheme de conținut, gândiți-vă la viitor. Lucrând pentru o companie aeriană importantă nu în urmă cu un deceniu, îmi amintesc că am încercat să modelez conținut pentru dispozitive mobile (da! exista un subdomeniu separat pentru un site web mobil). Acest lucru a fost extrem de dificil, deoarece schemele de conținut erau orientate doar către un site web desktop. Dar povestea este adevărată și astăzi că trebuie să fim vigilenți cu privire la modelarea conținutului.
Ai grijă la:
Crearea de conținut grozav
Fie că este un CMS tradițional sau un CMS fără cap, principala cerință este gestionarea conținutului. Autorilor de conținut ar trebui să le placă să lucreze în back-office. Dacă vedeți că autori apelează la alte instrumente de creație, cum ar fi Google Docs, pentru capabilitățile sale de comentarii sau sugestii, poate fi un semnal roșu cu privire la caracteristicile care vă lipsesc.
Documentele Microsoft Word, foile de calcul, documentele Google își ridică întotdeauna capul când lucrează cu autorii de conținut. În loc să încerci să-i alungi din timp, cel mai simplu mod de a-i determina pe autorii de conținut să lucreze la CMS este să le oferi funcțiile de care au nevoie și le vor elimina automat. Când am lansat propriul site web Luminary live pe un CMS fără cap, fiecărui membru al echipei (50 dintre ei) a primit suficient acces pentru a adăuga și edita propriul profil pentru site. A funcționat de minune fără a avea 50 de documente Google zburând peste tot.
Experienta de editare
Decizia de a utiliza un CMS fără cap poate fi o decizie IT. Dar acceptarea din partea agenților de marketing și a autorilor de conținut din cadrul organizației este esențială pentru adoptarea și succesul acesteia. Un CMS fără cap, care permite autorilor de conținut să introducă conținut cu ușurință, să găsească conținut existent și să reutilizeze conținutul este ceva care ar trebui să iasă din cutie.
Pentru ușurința creării conținutului, este necesar să aveți editori ușor de utilizat, cum ar fi editori WYSIWYG, editori de text, meniuri derulante și editoare personalizate. Va fi apreciată o interfață curată și minimalistă care permite unui autor de conținut să se concentreze asupra sarcinii în cauză. O interfață de editare care permite editarea, comentarea și crearea simultană a elementelor de conținut secundar în aceeași interfață va crește productivitatea autorilor de conținut.
Un cuvânt de precauție atunci când utilizați editori WYSIWYG sau dependență puternică de orice interfață de editare care produce HTML. Întrucât un CMS fără cap este conceput pentru a satisface mai multe canale, bazarea pe editorii WYSIWYG ar elimina natura atomică a conținutului care poate fi reutilizat. Asigurați-vă că editorii personalizați permit accesarea câmpurilor de date la un nivel granular . Am văzut că acest lucru împiedică reutilizarea conținutului pe diferite canale, cum ar fi mobil și desktop, de exemplu.
Cu un CMS fără cap, organizarea elementelor de conținut într-o structură arborescentă nu este o normă. Dar este o punte care le permite autorilor de conținut să treacă cu ușurință de la un CMS tradițional la unul Headless. Dacă elementele de conținut nu sunt vizualizate într-o structură arborescentă, un motor de căutare puternic, cu fațete și capabilități de etichetare este esențial pentru editorii dvs. de conținut. Acest lucru le permite autorilor să găsească și să refolosească cu ușurință conținutul existent.
Când reutilizați conținut, un alt aspect de luat în considerare este dacă elementele de conținut pot fi imbricate cu ușurință în alte elemente de conținut. Acest lucru permite reutilizarea maximă a conținutului existent. Atenție însă la referințele circulare la conținut care ar putea provoca dureri de cap și probleme de performanță. Un exemplu este un articol de conținut pentru un avocat care este legat de un articol de conținut pentru o expertiză. Apoi, dacă elementul de conținut de expertiză este din nou legat de mai multe articole de conținut de avocat, aceasta ar putea forma o referință circulară. Căutați un CMS fără cap cu inteligență integrată pentru a limita profunzimea API și vizualizări pentru a afișa elementele de conținut conectate pentru a evita această capcană.
Ai grijă la:
O imagine valorează: cum să gestionați mediile
O imagine valorează cât o mie de cuvinte. Dar activele de imagine sunt greu de transportat, greu de organizat și greu de căutat. Într-un CMS obișnuit, veți vedea duplicate și elemente de imagine prost numite în timp. Este important ca editorii de conținut să primească instrumente pentru a organiza, clasifica, eticheta, reutiliza și căuta imagini într-un CMS fără cap. Pentru mine, asta înseamnă organizarea activelor în foldere sau containere. Dar ar fi bine să înțelegeți ce necesită echipa dvs. în ceea ce privește gestionarea activelor statice.
Capacitatea de a încărca o singură imagine, de a seta un punct focal pentru ea și apoi de a-i manipula dimensiunile și calitatea pentru diferite dispozitive și dimensiuni de ecran, aduce economii masive de timp unui editor de conținut și chiar și acelor designeri/artiști grafici care lucrează în culise. Livrarea de active statice în formate precum WebP printr-o rețea de livrare de conținut (CDN) este, de asemenea, crucială pentru a oferi utilizatorilor un site web rapid.
Majoritatea CMS-urilor fără cap vin cu aceste funcții din cutie. Dacă nu, trebuie să decideți fără de ce funcții puteți trăi. Există o avertizare la această regulă. Pentru o editare extensivă a imaginilor originale, ar trebui să respectați cele mai bune instrumente pentru această activitate, cum ar fi Photoshop.
Alături de imagini, următoarele cele mai grele active sunt videoclipurile. Încă o dată, cu mentalitatea microserviciilor, streamingul de videoclipuri ar trebui lăsat în seama furnizorilor de servicii, cum ar fi YouTube, Vimeo și alte servicii de streaming online. Dacă CMS-ul tău fără cap îți poate oferi o interfață de editare frumoasă pentru a căuta sau a selecta un videoclip de la unul dintre acești furnizori, este un bonus.
Ai grijă la:
Roluri de autor
Cine poate introduce conținut și cine poate aproba sau publica conținut pe un site live și alte permisiuni granulare trebuie gestionate și prin intermediul CMS-ului fără cap. O echipă de două persoane ar putea supraviețui fără a avea roluri de autor distincte, dar pe măsură ce organizațiile și echipele de conținut cresc, rolurile de autor sunt o necesitate.
Am lucrat cu echipe de conținut de peste 40 de editori și această cerință trebuie evaluată cu atenție în raport cu CMS-ul fără cap pe care l-ați ales. Dacă nu, va domni pandemoniul. Cu echipa de 40 de persoane cu care am lucrat, am avut redactori, traducători, personal QA și autorizatori juridici care aveau permisiuni diferite pentru a accesa anumite conținuturi , variante de limbă, aprobări ale fluxului de lucru și drepturi de publicare.
Numărul de roluri distincte și de utilizatori back-office este de obicei modul în care CMS-urile fără cap își structurează prețurile. Când comparați prețurile între furnizori, gândiți-vă la cifrele actuale și la creșterea viitoare a echipei dvs. de conținut.
Ai grijă la:
Fluxuri de lucru
Nu fiecare element de conținut trebuie gestionat printr-un flux de lucru. Dar când sunt necesare fluxuri de lucru, piste de audit și aprobări, procesul trebuie gestionat în CMS-ul tău fără cap. Având un flux de lucru robust construit de la zero pe CMS-ul tău fără cap, îți oferă liniște sufletească și oportunitatea de a gestiona fiecare articol de conținut în conformitate cu procesul tău de afaceri. Capacitatea de a integra sisteme terțe prin webhook-uri sau API-uri este un bonus la care ar trebui să fii atent.
Ai grijă la:
Previzualizări de conținut
Editorul de conținut a creat conținutul, a adăugat imagini și l-a trimis printr-un flux de lucru pentru aprobare. Dar unde previzualizează conținutul înainte ca acesta să fie pus la dispoziția publicului larg? Aici intră în joc API-urile de previzualizare pentru a prelua conținut nepublicat și capacitatea de a seta medii de previzualizare.
Cu un CMS fără cap, după ce s-au îndepărtat de la un singur canal de gândire, editorii dvs. de conținut nu ar trebui să se aștepte să vadă previzualizări de pagină completă în back-office-ul CMS. Fiecare canal ar trebui să aibă propriul mediu de punere în scenă sau de previzualizare pentru a vedea conținutul nefinalizat care nu a fost încă publicat. Acesta poate fi un site de pregătire pentru site-ul dvs. web sau o versiune instalată local a aplicației dvs. pentru mobil. O funcție de previzualizare trebuie să fie disponibilă în planul de prețuri pe care l-ați ales pentru CMS-ul fără cap la alegere.
Ai grijă la:
Locale
Dacă conținutul dvs. trebuie difuzat în locații diferite, această cerință trebuie identificată la începutul proiectului. Modernizarea este posibilă, dar nu este o activitate distractivă. Modul în care gestionați conținutul și activele în diferite culturi și limbi ar trebui gândit și documentat. Aș recomanda crearea unui plan pentru a identifica ce limbi și active moștenesc sau implicit de la altul. Apoi asigurați-vă că alegerea dvs. de CMS fără cap acceptă acel plan sau explorați căi pentru a obține același rezultat în mod diferit.
Ai grijă la:
Crearea de conținut grozav este întotdeauna importantă. Astfel, autorilor de conținut ar trebui să li se ofere cea mai bună experiență posibilă în activitățile lor de zi cu zi pentru a face tranziția dvs. la CMS fără cap un succes.
„
Timpul dezvoltatorului este prețios
Cu un CMS fără cap, implicarea dezvoltatorilor este o necesitate. Acesta ar putea fi un dezvoltator back-end sau un dezvoltator front-end care consumă API-ul headless pentru a afișa conținut pe site. Dar odată ce dezvoltarea inițială este finalizată, un autor de conținut ar trebui să poată lucra cu o intervenție minimă. Acesta este scopul folosirii unui CMS. Este valabil și pentru CMS-urile fără cap.
Oricât de mult sunt luați în considerare autorii de conținut atunci când se compară caracteristicile, ar trebui explorate și funcțiile pentru dezvoltatori. În această secțiune, vom analiza funcțiile care vor economisi timp pentru dezvoltatori.
Suport API/GraphQL
Un API matur, care permite selectarea, paginarea și proiecția elementelor de conținut, este esențial pentru ca un dezvoltator să lucreze cu un CMS fără cap. Suportul gratuit pentru GraphQL este un alt factor definitoriu, deoarece va permite dezvoltatorului să definească rezultatul de care are nevoie la un nivel foarte granular. O documentație cuprinzătoare și mostre de cod sunt, de asemenea, o necesitate.
Asigurați-vă că dezvoltatorii dvs. sunt mulțumiți de API-urile de recuperare a conținutului înainte de a vă angaja la un CMS fără cap. Nu uitați API-urile de previzualizare, API-urile securizate și ușurința utilizării lor prin cod. Doriți să automatizați crearea de conținut? Atunci ar trebui luate în considerare API-urile de gestionare a conținutului .
API-urile de gestionare a conținutului au fost o binecuvântare în care am automatizat importul a peste 2.000 de postări de blog de pe un site WordPress într-un CMS fără cap. Toate postările de blog și imaginile aferente au fost importate cu o muncă minimă pentru autorii de conținut. Unele CMS-uri fără cap oferă suplimente Google Sheets și alte instrumente ingenioase pentru a face acest lucru printr-un clic pe un buton.
Cu multe CMS-uri fără cap care oferă probe gratuite, este o idee bună să le duceți la un test drive pentru a vedea adecvarea și conformitatea lor cu alegerea dvs. de creare și preluare a conținutului.
Ai grijă la:
SDK-uri native
Kiturile de dezvoltare software (SDK) pentru diverse tehnologii, limbi și platforme sunt disponibile direct de la furnizorul Headless, o inițiativă open-source sau o terță parte. Asigurați-vă că aceste SDK-uri acceptă tehnologia, limba și platforma pe care vă veți construi site-ul sau aplicația pentru consumatori. Pe măsură ce API-urile RESTful și GraphQL vă permit să interogați conținut, a avea un SDK nativ ar putea reduce orele de dezvoltare destul de semnificativ .
La Luminary, lucrul cu SDK-uri native pentru CMS-uri headless ne-a permis să îmbrățișăm cele mai noi tehnologii, cum ar fi Microsoft .NET Core și .NET 5. De asemenea, construirea pe baza unui SDK existent ne-a permis să respectăm cele mai bune practici recomandate de furnizor în timp ce economisim timp.
Ai grijă la:
Medii
Un site web sau o aplicație pentru un magazin pentru mamă și pop ar putea să organizeze și să previzualizeze conținutul într-un singur mediu de producție. Dar, pe măsură ce organizațiile, echipele și funcțiile cresc, devin necesare mai multe medii pentru gestionarea și previzualizarea conținutului. Nu numai că CMS-ul tău fără cap trebuie să ofere medii, dar și aplicația consumatoare ar trebui să aibă medii configurate. Trebuie luate în considerare metodele de reîmprospătare a conținutului în diferite medii.
Ai grijă la:
Imagini, Fișiere și CDN-uri
Am abordat gestionarea imaginilor atunci când vorbim despre funcții pentru autorul conținutului. Din perspectiva dezvoltatorului, nu numai activele statice trebuie să fie stocate în cache pe un CDN. Multe CMS-uri fără cap memorează în cache conținutul preluat prin API-urile RESTful sau GraphQL. Acest lucru accelerează procesul de recuperare și aduce îmbunătățiri de performanță aplicației dvs.
Deși stocarea în cache CDN este super utilă, există momente în care corupția cache-ului sau elementele mai vechi din cache pot crea probleme . Capacitatea de a curăța memoria cache CDN sau abilitatea de a extrage cel mai recent conținut cu antete HTTP specifice ar trebui să facă parte din funcționalitatea API a CMS-ului fără cap.
Abilitatea de a utiliza domenii personalizate împotriva unui CDN pentru a vă livra conținutul sau activele statice ar putea fi o cerință pe care trebuie să o luați în considerare.
Ai grijă la:
Limite de utilizare în toate planurile
Un alt factor de luat în considerare este limitele de utilizare stabilite pentru fiecare plan la care vă abonați pentru CMS-ul fără cap la alegere. Trebuie luate în considerare numărul de elemente de conținut, consumul de lățime de bandă, numărul de utilizatori back-office, numărul de apeluri API și limitele de rată. Când planificați limitele de utilizare, luați în considerare utilizarea curentă și utilizarea viitoare. Amintiți-vă că multe CMS-uri fără cap funcționează pe bază de abonament și vă permit să faceți upgrade aproape instantaneu la planuri cu limite mai mari.
Cu toate acestea, merită să fiți conștienți de câți utilizatori vor folosi platforma și dacă soluția ar trebui să se extindă masiv. Am fost martorii unui client care a primit o factură foarte mare, deoarece a adăugat fără să vrea un număr mare de utilizatori peste cota alocată. Este o idee bună ca administratorii să fie conștienți de ceea ce oferă planul lor Headless și să țină cont de utilizare.
Luați în considerare menținerea sub limitele de utilizare a limitelor dvs. actuale cu stocarea în cache pe partea clientului, generatoare de pagini statice și apeluri inteligente API sau GraphQL pentru a vă reduce cheltuielile de operare.
Ai grijă la:
Timpul unui dezvoltator este scump. În timp ce un CMS fără cap este prezentat ca un CMS prietenos pentru dezvoltatori, fiecare furnizor are caracteristici diferite pe care le acceptă în mod nativ. Este foarte recomandat să înțelegeți și să le comparați cu nevoile dezvoltatorilor dvs.
„
Alti factori
Există alți câțiva factori care ar putea să nu afecteze autorul conținutului sau dezvoltatorul. Acest lucru poate varia de la marketing la finanțare până la cerințele legale și de reglementare pentru industria și afacerea dvs.
Locațiile centrelor de date
O întrebare care ni se pune adesea este, unde sunt stocate datele? Da, în nor. Dar care centru de date geografic este o întrebare importantă din cauza cerințelor legale și de reglementare ale anumitor afaceri. Un CMS fără cap, care vă permite să stocați date în centrul de date ales de dvs., ar putea fi un factor critic în a decide ce CMS alegeți.
Suport tehnic și vânzări
Capacitatea de a primi asistență tehnică și de vânzări în fusul dvs. orar este un alt factor decisiv atunci când alegeți CMS-ul fără cap. Lipsa unui agent de vânzări local a îndreptat multe proiecte în favoarea acelor vânzători care au oameni pe teren în regiunea relevantă.
Am avut o mare organizație NFP (Nu pentru profit) care a ales un furnizor de CMS fără cap datorită capacității de a stoca date într-un centru de date Azure din Australia. Având asistență de vânzări la sol și asistență tehnică non-stop, a câștigat vânzarea pentru acel furnizor de CMS fără cap.
Ai grijă la:
Caracteristici de întreprindere de luat în considerare
Unele organizații mari ar putea necesita o conectare unică (SSO) legată de sistemul de autentificare al companiei sau de jurnalele de audit care pot fi interogate cu ușurință. S-ar putea să existe integrări la sistemele existente și anumite certificări ISO care trebuie să fie implementate înainte ca un produs SaaS să fie considerat potrivit. Crearea unei liste cu aceste funcții de întreprindere și altele unice pentru organizația dvs. la nivel de întreprindere este un bun punct de plecare atunci când alegeți un CMS fără cap.
Comunitatea în acțiune
O altă zonă de obicei trecută cu vederea este comunitatea din jurul unui anumit CMS fără cap. Există oameni pasionați de produs? Nu vorbesc despre știrile de marketing ale vânzătorului. Există suficiente resurse open-source partajate de persoanele care folosesc instrumentul? Acesta poate să nu fie un factor decisiv, dar vă va ajuta atunci când vă aflați într-o situație dificilă în timpul fazei de implementare sau de sprijin a unui proiect.
Integrarea infrastructurii
Cu CMS-uri fără cap, nu sunteți legat de tehnologie, limbaj sau platformă. Tehnologia sau platforma pe care este construit CMS-ul headless nu influențează aplicația client. Puteți utiliza o tehnologie la alegere de la .NET la Node.js, sistemul de operare ar putea fi Windows, Linux sau macOS, iar limbajul dvs. poate fi orice, de la Python la C#.
În mod similar, atunci când vine vorba de achiziționarea infrastructurii, puteți alege să vă găzduiți site-ul pe Netlify, Azure, GCP sau AWS. Arhitectura site-ului dvs. și deciziile privind infrastructura se bazează acum exclusiv pe cerințele dvs. Există, de asemenea, integrări native de primă clasă cu servicii precum Gatsby Cloud, care aduc mai multe combo-uri care vă fac viața mai ușoară. Pentru unii, aceasta ar putea fi o decizie majoră și ar trebui luată discutând cu niște practicieni experți din spațiul Headless.
Ai grijă la:
Experiența noastră la Luminary
La Luminary, am fost norocoși să colaborăm cu CMS-uri fără cap, cum ar fi Acoustic, Contentful, Kentico Kontent și Umbraco Heartcore. Lucrăm cu unele dintre aceste CMS-uri încă de la versiunile beta ale platformelor lor. Planurile de parcurs publice, asistența tehnică extraordinară și soluționarea solicitărilor noastre de funcții au fost câteva dintre cele mai importante noastre platforme.
Am avut experiență în abordarea SEO pentru site-urile web Headless cu implementări doar front-end, stocarea în cache a paginilor mari de listă, gestionarea cache-urilor mari de pe server și integrarea altor microservicii cu CMS-uri headless. Fiecare dintre acestea a avut provocările sale unice la care ar trebui să fii atent. De asemenea, sarcinile simple pe un CMS tradițional, cum ar fi trimiterea formularelor și căutarea pe site, trebuie bine gândite, împreună cu funcții mai avansate, cum ar fi autentificarea utilizatorilor și autorizarea cu servicii terțe.
Dacă alegeți CMS-ul corect fără cap cu indicatoarele de mai sus și cu partenerul de implementare corect, ar trebui să ajungeți cu un CMS fără cap care îi face pe marketeri fericiți, editori de conținut fericiți și dezvoltatori fericiți.