Headless CMS

El trabajo de los autores sería mucho más co­m­pli­ca­do si no exi­s­tie­ran sistemas de gestión de contenido. Con un CMS el contenido se edita en el backend y se muestra en el frontend, en lugar de hacerlo di­re­c­ta­me­n­te en el código de la página web. Esto funciona de manera óptima si se gestiona una única página, pero los re­da­c­to­res y los di­re­c­to­res de contenido suelen ad­mi­ni­s­trar varias páginas y apli­ca­cio­nes a la vez. Para ello se necesita más de un CMS, lo que significa que los co­n­te­ni­dos deben tra­s­la­dar­se de uno a otro o, por otro lado, recurrir a un headless CMS que permita la edición en medios di­fe­re­n­tes.

Un headless CMS es tanto una evolución como una reducción a partir de un CMS clásico: algunos co­m­po­ne­n­tes in­te­gra­les del sistema son retirados para hacerlo co­m­pa­ti­ble con las tareas más diversas. Esto es posible porque en un headless CMS tanto el frontend como el backend no están vi­n­cu­la­dos de forma mo­no­lí­ti­ca entre sí.

Para que resulte sencillo utilizar estos sistemas, se recurre a una relación mo­no­lí­ti­ca entre frontend y backend. En la interfaz de ad­mi­ni­s­tra­ción de WordPress, por ejemplo, el aspecto de la página se puede modificar con ayuda del generador de pla­n­ti­llas aun sin contar con ex­pe­rie­n­cia en diseño web. Esto también significa que la creación de contenido está ligada a las normas del sistema, lo que se aplica tanto al número de tareas como a la uti­li­za­ción del lenguaje de pro­gra­ma­ción (en WordPress se emplea PHP). Para sortear estas li­mi­ta­cio­nes se puede recurrir a un headless CMS.

Una API REST (Re­pre­se­n­ta­tio­nal State Transfer) es una interfaz no muy compleja pero sí muy flexible que emplea métodos de consulta definidos como HTTP PUT, GET, POST y DELETE para co­mu­ni­car­se, comandos por medio de los que un cliente puede acceder a los datos del servidor, so­li­ci­tar­los o mo­di­fi­car­los. Por lo tanto, REST sigue fu­n­da­me­n­ta­l­me­n­te el estilo de ar­qui­te­c­tu­ra de la Web. Las API REST, también conocidas como “API RESTful”, se co­n­s­tru­yen en base a estos criterios:

• Los se­r­vi­do­res facilitan los recursos: una API REST también está di­s­po­ni­ble para apli­ca­cio­nes externas a través de un servidor. Por lo tanto, el acceso no funciona solo de manera local.

• Las di­re­c­cio­nes ide­n­ti­fi­can elementos: los di­fe­re­n­tes tipos de apli­ca­cio­nes requieren diversos formatos de archivos. En REST, el URI/URL no toma como re­fe­re­n­cia a un recurso en un formato de­te­r­mi­na­do, sino al elemento en sí. Mediante la ne­go­cia­ción de contenido, los clientes pueden solicitar el elemento en el formato deseado.

• Los mensajes son claros y evidentes: cada mensaje dirigido al servidor es un mensaje cerrado en sí mismo que no hace re­fe­re­n­cia a uno anterior.

• Vi­n­cu­la­ción de los recursos mediante enlaces: en REST, los objetos están co­ne­c­ta­dos entre sí por medio de hi­pe­re­n­la­ces, lo que resulta en una na­ve­ga­ción sencilla.

Si se siguen estos pri­n­ci­pios es­tru­c­tu­ra­les, la co­mu­ni­ca­ción entre servidor/API y los di­fe­re­n­tes clientes tiene lugar sin problemas, de ahí que la ar­qui­te­c­tu­ra REST resulte perfecta para la API de un headless CMS.

Esta se­pa­ra­ción resulta útil desde dos pe­r­s­pe­c­ti­vas. Desde el punto de vista del de­sa­rro­llo del backend, existe el deseo de divulgar el contenido en más de una edición. En un headless CMS no importa la pla­ta­fo­r­ma a través de la que se di­s­tri­bu­yen los co­n­te­ni­dos, pues la API REST solo pro­po­r­cio­na los datos (en formato JSON), los cuales pueden leerse desde cualquier tipo de frontend in­de­pe­n­die­n­te­me­n­te de la te­c­no­lo­gía con las que se programen.

También aparecen ventajas desde el punto de vista del de­sa­rro­llo del frontend: al utilizar un headless CMS, los di­se­ña­do­res web ya no están ligados a las co­n­di­cio­nes del gestor de co­n­te­ni­dos, de la misma forma que el lenguaje de pro­gra­ma­ción tampoco está definido. Esto permite la creación de apli­ca­cio­nes móviles en di­ve­r­si­dad de pla­ta­fo­r­mas. Úni­ca­me­n­te han de recibirse y editarse los datos brutos, lo que ofrece un margen más amplio de maniobra en su pre­se­n­ta­ción que con los CMS clásicos.

Otra de las ventajas es la capacidad de realizar so­li­ci­tu­des dinámicas. En los CMS clásicos la consulta de nuevos co­n­te­ni­dos en una página web suele hacer que la página se cargue de nuevo. Por el contrario, la API REST entrega datos dinámicos que se pueden integrar en cualquier momento en la es­tru­c­tu­ra de la página sin necesidad de volverlos a cargar. 

De la se­pa­ra­ción entre el backend del headless CMS y el frontend in­di­vi­dual surge una situación práctica: debido a las mo­di­fi­ca­cio­nes co­n­s­ta­n­tes en las te­n­de­n­cias del diseño web, es útil hacer ajustes de vez en cuando en la propia página web. Si esto no está ligado a la base de datos y al gestor de co­n­te­ni­dos, puede rea­li­zar­se de manera in­de­pe­n­die­n­te. Así, los re­da­c­to­res pueden seguir tra­ba­ja­n­do en el contenido mientras los di­se­ña­do­res editan el frontend.

Re­su­mie­n­do, las ventajas de un headless CMS son:

• Cantidad ilimitada de frontends
• Po­si­bi­li­dad de co­m­bi­nar­se con diversos lenguajes de pro­gra­ma­ción
• Diseño más flexible del frontend
• Co­n­ti­nui­dad mediante des­aco­pla­mie­n­to
• Datos dinámicos

El mercado ya cuenta hoy en día con algunos sistemas headless de gestión de contenido, pero su número va en aumento. Los fa­bri­ca­n­tes que aparecen a co­n­ti­nua­ción se di­fe­re­n­cian pri­n­ci­pa­l­me­n­te en si ofrecen un paquete de pago o una versión open source, pero también pro­po­r­cio­nan di­fe­re­n­tes opciones de hosting.

• Co­n­te­n­t­ful: este equipo sito en Berlín trabaja desde 2011 en el principio de los headless CMS. Han de­sa­rro­lla­do su sistema desde cero, incluido un potente backend, en lugar de partir de un CMS al uso. La propuesta, sin embargo, solo es gratuita de forma limitada.

• Directus: Directus va en otra dirección. El sistema está di­s­po­ni­ble en principio como paquete open source gratuito, pero si se quiere recurrir a una al­te­r­na­ti­va alojada, se puede optar por di­fe­re­n­tes opciones de su­s­cri­p­ción.

• Co­n­te­nts­ta­ck: Built.io, fa­bri­ca­n­te de varias so­lu­cio­nes digitales, ofrece con Co­n­te­nts­ta­ck un headless CMS de pago. Con este sistema, los creadores de contenido pueden acceder a un backend muy fácil de usar que gracias a una API REST puede facilitar contenido para la Web, las apli­ca­cio­nes móviles y el Internet de las Cosas. Esta solución está destinada pri­n­ci­pa­l­me­n­te a empresas de gran en­ve­r­ga­du­ra.

• Cloud CMS: este proveedor de servicios ofrece su headless CMS como solución en la nube, la cual funciona como cualquier otra he­rra­mie­n­ta de estas ca­ra­c­te­rí­s­ti­cas, con la pa­r­ti­cu­la­ri­dad de que la gestión del contenido, la base de datos y la interfaz no se alojan en tu propio sistema, sino en la nube del proveedor. Si recurres al segmento más caro de este sistema puedes disfrutar de un CMS alojado por cuenta propia.

• eZ Platform: la empresa eZ Systems empezó a ofrecer en 1999 un CMS clásico con el producto de código abierto eZ Publish. 16 años después, se desechó el concepto original y la empresa se centró en un headless CMS con eZ Platform, una he­rra­mie­n­ta libre protegida bajo la licencia GNU GPL. Asimismo, también se puede recurrir a versiones de pago con asi­s­te­n­cia pro­fe­sio­nal.

Para decidirse por el headless CMS más adecuado se deben cue­s­tio­nar las ne­ce­si­da­des y los co­no­ci­mie­n­tos pa­r­ti­cu­la­res. Quien tenga un servidor propio y la capacidad de in­co­r­po­rar un CMS open source puede hacer uso de las versiones gratuitas de eZ Systems o Directus. Si no tienes los co­no­ci­mie­n­tos para instalar y co­n­fi­gu­rar el sistema, debes entonces recurrir a una versión de pago para poder be­ne­fi­ciar­te de todas las ventajas de este sistema de gestión de co­n­te­ni­dos.

Cada vez se habla más de los headless CMS, por lo que los pro­vee­do­res de los CMS tra­di­cio­na­les están cambiando de pe­r­s­pe­c­ti­va. WordPress, por ejemplo, ha integrado la API REST como co­m­po­ne­n­te integral a partir de la versión 4.7. En las versiones an­te­rio­res esta solo podía co­ne­c­tar­se mediante un plugin, por lo que la extensión no lo convierte en un headless CMS, sino más bien en un decoupled CMS. Los usuarios que le dan valor al alcance y al generador de pla­n­ti­llas de esta solución pueden trabajar sin pérdidas fu­n­cio­na­les. No obstante, quien quiera usar el CMS para gestionar los co­n­te­ni­dos de una app puede sacarle partido a las in­te­r­fa­ces. Drupal también puede tra­n­s­fo­r­mar­se en un híbrido, pues el hecho de que este CMS open source pro­po­r­cio­ne los servicios web RESTful a partir de la versión 8 plantea la po­si­bi­li­dad de di­s­tri­buir co­n­te­ni­dos en muchos frontends.

Cambiar de un sistema con el que se está fa­mi­lia­ri­za­do a un headless CMS depende pri­n­ci­pa­l­me­n­te del proyecto. Si solo quieres presentar tus co­n­te­ni­dos en una página web como un blog, no es re­co­me­n­da­ble pre­s­ci­n­dir del frontend. Los headless CMS también plantean ventajas que so­bre­pa­san el volumen de los posibles modelos de salida, lo que rara vez justifica el esfuerzo. La uti­li­za­ción de un decoupled CMS, no tiene, por su parte, un valor añadido: ¿para qué im­ple­me­n­tar una interfaz si solo se utiliza el frontend in­co­r­po­ra­do en el sistema?

La situación es distinta cuando se utillizan di­fe­re­n­tes pla­ta­fo­r­mas. Los headless CMS pueden ser una al­te­r­na­ti­va óptima si se quieren crear proyectos de gran en­ve­r­ga­du­ra, ya se trate de proyectos mu­l­ti­ca­nal, de páginas web en PHP, Python o Ruby, o de apps para iOS o Android. Los creadores de contenido pueden seguir ge­s­tio­ná­n­do­los a través de la interfaz de manera habitual. En los headless CMS (y al usar decoupled CMS co­rre­c­ta­me­n­te), los frontend de­ve­lo­pe­rs pro­fe­sio­na­les son los que se ocupan de la pre­se­n­ta­ción, pero también se puede recurrir a la API REST.

La re­mo­de­la­ción (no se puede hablar de reducción de sistemas cuando se habla de de­sa­rro­llo) de los sistemas de gestión de contenido es una reacción a las ne­ce­si­da­des ca­m­bia­n­tes de Internet. Las pa­r­ti­cu­la­ri­da­des de los sma­r­t­pho­nes, del Internet de las Cosas o de las reali­da­des virtuales hacen necesario hallar un nuevo concepto para crear y publicar contenido. Los headless CMS y los decoupled CMS solo son el principio. Por ello, incluso cuando ac­tua­l­me­n­te es su­fi­cie­n­te trabajar con un CMS tra­di­cio­nal, no hay que perder de vista las nuevas te­n­de­n­cias. En vista de la rápida evolución de los últimos años, es posible que los CMS clásicos ya no se ajusten a las co­s­tu­m­bres y ne­ce­si­da­des de muchos usuarios, como es el caso de las páginas web estáticas.