Què és un CMS headless i quan convé

La decisió entre una arquitectura i una altra es pren una vegada i condiciona els anys següents. El següent són els criteris que la determinen, inclosos els que apunten a quedar-se en un gestor tradicional.

L'arquitectura rendeix quan es compleix almenys una d'aquestes condicions:

• El contingut alimenta més d'un canal. Web pública, aplicació, catàleg intern, pantalles, integració amb un ERP o amb un configurador de producte.
• El catàleg és gran i estructurat. Centenars de fitxes amb camps comuns, filtrables i relacionades entre si, on cada camp s'ha de poder consultar per separat.
• El lloc funciona en diversos idiomes amb contingut propi de cada mercat, més enllà de la traducció del mateix text.
• La interfície té requisits que un tema no cobreix. Animació sincronitzada amb el desplaçament, models tridimensionals, configuradors, qualsevol peça on l'experiència sigui part del producte.
• El projecte creixerà durant anys i el cost de refer-lo cada tres s'ha convertit en un problema conegut.
• El rendiment és un requisit de negoci, no una aspiració. Un lloc generat en temps de construcció parteix d'un avantatge difícil d'igualar amb un gestor que compon cada pàgina a cada visita.

Un senyal fiable: si en descriure el projecte apareixen les paraules "i també hauria d'aparèixer a…", l'arquitectura headless probablement té sentit.

Aquesta secció importa més que l'anterior, perquè és la que gairebé ningú escriu. Abans d'entrar-hi convé separar dues coses que solen anar barrejades: les limitacions que són pròpies de l'arquitectura i les que depenen de com es va plantejar el projecte. Les segones són reals, es troben sovint, i s'eviten amb decisions que es prenen abans d'escriure la primera línia de codi.

Comencem per dos criteris que se citen com a propis de l'arquitectura i no ho són.

El primer és la mida. Un lloc de deu pàgines amb cinc idiomes, dades estructurades per tipus d'entitat i un catàleg que creixerà és millor candidat que dues-centes entrades de blog sense estructura. El nombre de pàgines no diu res sobre l'arquitectura que necessita.

El segon és publicar contingut de manera habitual. Els gestors headless actuals inclouen vista prèvia del lloc real, no una aproximació dins de l'editor, i qui publica entrades en un gestor tradicional publica en un headless amb una formació breu. A canvi, el lloc no arrossega extensions per actualitzar, incompatibilitats entre elles ni la superfície d'atac d'un sistema que executa codi a cada visita.

El tercer és el condicional, i mereix detall. Es diu que en headless l'equip no pot muntar pàgines noves sense ajuda. Passa, i amb freqüència, però no per l'arquitectura: passa quan el projecte es va construir com un conjunt de plantilles fixes. Si en canvi es defineix des del principi un catàleg de components amb les seves variants de disseny i es col·loquen en zones dinàmiques, l'editor compon pàgines completes triant blocs i ordre. La diferència entre les dues situacions és una decisió de disseny de sistema presa abans de començar, no una propietat del gestor.

El que sí que requereix desenvolupament en qualsevol cas és ampliar aquest catàleg. Una calculadora de pressupost, un configurador, un cercador amb filtres que abans no existien: això és funcionalitat nova i cal construir-la. La diferència amb un gestor tradicional no és en la maquetació, és que allà una part d'aquesta funcionalitat de vegades es compra ja feta.

D'aquí en surten tres preguntes que convé fer a qualsevol proveïdor abans de signar, i les respostes de les quals prediuen força bé com serà l'any següent al llançament:

• Quines pàgines podré muntar sense trucar-vos, i amb quins blocs.
• Què passa quan necessiti alguna cosa que avui no està prevista, i com es pressuposta.
• Qui pot continuar aquest projecte si deixem de treballar junts.

Els casos en què la resposta correcta sí que és un gestor tradicional:

• No hi ha ni hi haurà accés continuat a algú que toqui codi. És el criteri decisiu. Sense desenvolupador (intern, agència o tercer), un projecte headless queda congelat tan bon punt el negoci necessiti alguna cosa que no estava prevista.
• El negoci depèn de funcionalitat de tercers, present o futura. Reserves, membresies, formació, comerç amb configuracions específiques, eines de càlcul. Si l'operativa es recolza en diverses extensions, o si és previsible que les necessitats futures es resolguin comprant en lloc de construint, l'ecosistema pesa més que l'arquitectura.
• El pressupost o el termini no absorbeixen l'arrencada. La capa visible s'ha de construir, i la feina de definir el model de contingut i el catàleg de components va per davant de la primera pantalla visible. Si el projecte surt en tres setmanes amb recursos ajustats, la decisió és una altra, i no és una mala decisió.
• Un comerç electrònic estàndard sense necessitats particulars d'interfície ni integracions fora del comú, on una plataforma especialitzada resol el conjunt.

Aquest primer punt és el que més pesa i el que menys es pregunta a l'hora de decidir. Els altres tres tenen solució amb pressupost; aquest no.

I convé dir que l'error va en les dues direccions. Un catàleg de mil referències amb integracions muntat sobre un gestor tradicional acaba sostingut per una acumulació d'extensions que ja no es pot actualitzar sense por. Triar malament no es manifesta en el llançament: es manifesta dos anys després, quan el sistema deixa d'acompanyar allò que el negoci necessita.

És l'objecció que més apareix, i ve d'una confusió: la mala fama de les aplicacions que es construeixen senceres al navegador, on el cercador rep una pàgina buida i ha d'executar codi per veure el contingut.

Un projecte headless ben plantejat no funciona així. El contingut es genera al servidor o en el moment de construir el lloc, i arriba al cercador com a HTML complet. Des del punt de vista del rastreig, és indistingible d'un lloc tradicional.

El que sí que canvia és de qui és la responsabilitat. En un gestor tradicional, les etiquetes, el mapa del lloc, les URL canòniques i les dades estructurades les resol una extensió que algú instal·la. En headless no hi ha extensió: cadascuna d'aquestes peces es construeix, i si no es construeix, no existeix. No és un desavantatge de l'arquitectura, és un requisit del projecte que cal pressupostar des del principi.

L'avantatge és en el control. Quan les dades estructurades es generen a partir de camps definits en el model de contingut, deixen de dependre que algú ompli bé una caixa de text, i passen a construir-se com a part del treball de SEO tècnic sobre el mateix model de dades.

Un projecte headless comença sent més car. Cal construir la capa visible que un tema resoldria amb un projecte tradicional que cal reconstruir al cap de tres anys pot acabar resultant més car, configurar els tipus de contingut, muntar la vista prèvia i resoldre tot allò que en un gestor tradicional ja ve incorporat.

La comparació honesta no és la factura inicial: és el cost a tres o quatre anys, incloent-hi manteniment, llicències, incidències i la probabilitat d'haver de refer el lloc web. Un projecte tradicional que cal reconstruir al cap de tres anys pot acabar resultant més car que un de headless que es manté durant set. I a l'inrevés: un projecte headless en un lloc web que mai no va necessitar aquesta arquitectura són diners gastats en una complexitat que ningú no fa servir.

Per editar, poc: els panells dels gestors headless són senzills i la formació es mesura en hores. Qui publica una entrada en un gestor tradicional en publica una a Strapi sense dificultat.

Per mantenir-lo, més. Aquestes són les diferències reals del dia a dia:

• Compondre pàgines sí, ampliar el catàleg de blocs no, sempre que el projecte s'hagi definit així. Si es va construir amb plantilles fixes, qualsevol pàgina nova passa per desenvolupament. Convé preguntar-ho abans de signar, perquè després és car de canviar.
• Les actualitzacions són de codi, no d'un botó. Es planifiquen, es proven i es despleguen.
• Cal tenir accés a un desenvolupador, ja sigui intern, l'agència que el va construir o qualsevol altra. Aquí convé preguntar per l'stack: si està construït sobre tecnologies estàndard i amb documentació, qualsevol desenvolupador sènior el pot continuar. Si està construït sobre una solució propietària, no.
• La vista prèvia es configura, no ve incorporada. Els gestors headless actuals la porten com a funcionalitat, i mostra el lloc web real en lloc d'una aproximació dins de l'editor. Convé deixar-la a punt abans que l'equip comenci a publicar, no després.

Si la teva empresa no té ni tindrà accés continuat a algú que pugui tocar el codi, aquesta és una raó suficient per quedar-se en un gestor tradicional, encara que la resta de criteris apuntin en l'altra direcció.