¿Hay vida después del WordPress? Nuestra experiencia con Strapi + Eleventy.

En Paradigma hemos cambiado de imagen y, después de más de 6 años gestionando nuestra web con WordPress, era el momento de apostar por algo más moderno. Tras analizar varias opciones, decidimos desacoplar el CMS del frontal, usando Strapi y Eleventy.

Aquí os cuento cómo ha sido el camino hasta conseguirlo y las conclusiones que podemos sacar de esta travesía.

¿Por qué dar portazo a WordPress?

Mi experiencia con WordPress siempre ha sido buena y, aunque hay que entender que WordPress tiene algunos problemas asociados (para mí principalmente la seguridad), también ofrece muchas ventajas. Yo he conseguido hacer webs complejas con relativa facilidad y bastante control sobre su flujo de trabajo.

Dicho esto, con el nuevo cambio de marca de Paradigma venía asociado un cambio tan radical de la web, que sin duda tendríamos que empezar de cero, ya que cambiaba casi toda la estructura previa. Y nuestro WordPress, después de más de 6 años, ya había sufrido demasiados cambios de rumbo de la web y tenía demasiado “código zombie”.

La duda era si empezar desde cero con un nuevo WordPress, CMS con el que sabía que podríamos solventar todos los requisitos sin excesiva dificultad, o si por el contrario era el momento de arriesgarnos buscando un nuevo CMS.

Si por mí hubiese sido, me hubiera lanzado a por WordPress otra vez sin dudarlo. Pero mi compañero Luis Calvo me hizo la “inocente” propuesta de darle una pensada a los Headless CMS y ver si encajaba para nuestro caso.

¿Qué es un Headless CMS?
Es un gestor de contenido que solo proporciona un back-end y un API REST con el que consultar su contenido.
Mientras, un CMS tradicional combina el contenido y la capa de presentación, un Headless CMS se centra únicamente en el contenido.

Yo, que ya me estoy haciendo mayor, no había oído nunca hablar de un Headless CMS y, tras un primer vistazo, vi claro que reemplazar WordPress por un CMS de estos iba a ser una locura. Así se lo hice saber a Luis.

Al dejar PHP atrás y apostar por crear HTML estáticos, íbamos a perder toda la potencia de los plugins que hasta ese momento usábamos para cosas tan importantes como: la gestión de los comentarios, las búsquedas, programación de la publicación de nuevos artículos, gestión del SEO...

¿Qué son los generador de estáticos?
Son aplicaciones que, haciendo uso de los datos proporcionados, por ejemplo desde un API, crean ficheros HTML a través de un motor de plantillas. Son muy útiles para mantener los datos separados de la presentación.

Pero en Paradigma nos gusta "complicarnos la vida" y ya me habían metido el gusanillo en el cuerpo, ¡no iba a ser fácil sacarlo de allí!

Me seguí informando, viendo alternativas y evaluando posibles soluciones a los problemas que había previsto. Paso a paso la montaña se hizo más pequeña y, finalmente, pensamos que era el momento idóneo para darle una oportunidad al nuevo modelo.

Últimamente nos llegan muchos proyectos que buscan un Headless CMS y los experimentos siempre es mejor hacerlos con uno mismo.

Antes de tomar una decisión tan importante y con tanto impacto, decidimos hacer una prueba de concepto, para ver si merecía la pena el esfuerzo.

La alternativa

Tras estudiar las opciones disponibles sabíamos el modelo que queríamos. Tenía que ser una estructura en la que los datos y el frontal estuvieran desacoplados.

Debía de ser algo así:

Un CMS:

• Debía de ser sencillo e intuitivo para ser usado por nuestros editores.
• Con un código entendible y customizable por nuestros desarrolladores.
• Que generase un API Rest.
• Que tuviera un editor de contenidos preparado para trabajar por bloques.
• Hecho puramente con JavaScript.

Un generador de estáticos:

• Que creara todo el frontal de la web tan rápido como fuera posible.
• Control total sobre el código generado.
• Y también que esté desarrollado en JavaScript.

Y micro aplicaciones. Para las partes dinámicas de la web:

• Gestión de comentarios.
• Búsquedas.
• También encuestas.

Con este nuevo sistema esperábamos ganar mucho en seguridad y en tiempos de respuesta, pero también debía de seguir siendo igual de funcional que lo era Wordpress para nuestros editores y desarrolladores.

Teníamos los retos de no perder ninguno de estos puntos:

• Que los cambios hechos desde el CMS se vieran reflejados rápidamente en la web.
• Mantener la opción de poder añadir comentarios a los artículos y que cuando haya un nuevo comentario se notifique al autor de artículo.
• Poder mostrar porciones de código con sus colorinchis y tabulaciones dentro de los artículos.
• Poder programar la publicación de artículos.
• Poder **previsualizar los artículos **para que nuestros editores puedan ver cómo queda un artículo antes de ser publicado.
• No perder la eficiencia ni capacidad en la definición de las etiquetas de SEO.
• Gestión de las redirecciones de URL, para no penalizar el SEO.
• Seguir manteniendo la versión inglesa del site.
• Poder añadir varios autores a un artículo.
• Mantener las encuestas de los versus.
• Mostrar artículos relacionados.
• RSS para news feed.

Nuestra elección de Headless CMS

Hay muchísimas opciones en el mercado y el mejor lugar para encontrar el Headless CMS que mejor encaje contigo es headlesscms.org. Ahí podrás filtrar los CMS por tipo, licencia, lenguaje y popularidad.

Tras revisar las opciones que nos proponía esta web, hicimos una prueba de concepto con 4 candidatos:

Directus

Me gustaba mucho y cubría muchas de nuestras necesidades. Pero está desarrollado en PHP, y para este proyecto queríamos apostar por hacerlo 100% con JavaScript.

Netify CMS

Es muy popular, pero...

• No me gusta el modo de editar contenido.
• Por lo que entendí, no lo alojas directamente tú, y en este caso queríamos tenerlo todo en nuestros servidores.
• El contenido se almacena en páginas de GIT. Cosa que por una parte es muy potente, sobre todo para la gestión de cambios, pero que seguramente por lo viejuno que me he vuelto, me cuadraba mucho más el guardar los registros en base de datos.

Ghost

• Posiblemente el mejor editor de contenido de los que vi.
• Muy enfocado para desarrollar blogs,.
• Incluye el generador del frontal, lo que tiene innegables beneficios.

Ahora que lo he vuelto a revisar veo que ha crecido mucho y, si volviera a comenzar el proyecto, lo valoraría mucho más seriamente. Sinceramente ahora no recuerdo por qué lo descarté en su día.

Strapi

Finalmente nos decantamos por Strapi. Tiene algunos puntos fuertes que nos gustan mucho:

• Tiene una arquitectura muy sencilla y entendible.
• Es fácilmente customizable.
• Está completamente hecho con JavaScript. Strapi está desarrollado con React, pero la parte que debemos tocar para poderlo customizar es JavaScript nativo.

Por otro lado, también tenía algunos riesgos que daban un poco de miedo:

• Cuando comenzamos todavía estaba en versión Alpha. Ahora mismo está en Beta y ya se han solucionado muchos problemas, pero todavía le falta la madurez que ya tienen otros CMS.
• El editor de contenidos es demasiado básico, ya que tan solo se puede editar en modo Markdown, lo que hace imposible usar bloques de código visualmente complejos.
• La gestión de roles, para restringir el acceso a partes de la administración todavía no está desarrollada.

Pero a pesar de estos riesgos, el saber que los problemas que hemos encontrado son temporales (y sus muchas ventajas), nos ha hecho decantarnos por Strapi como nuestro nuevo editor de contenido.

Instalarlo y configurarlo es muy sencillo. Te iba a explicar cómo, pero creo que será mejor que lo mires directamente en su documentación, que está muy bien explicada.

Amplía Strapi como necesites

Strapi no encajaba al 100% con nuestras necesidades y hemos tenido que hacer algunas modificaciones para que se convierta en el CMS de nuestras vidas:

• Hemos desarrollado e integrado un nuevo editor de contenido, para que sea muy sencillo el crear y editar contenido, y usar todos los bloques que nuestros diseñadores habían creado.
• Hemos creado algunos nuevos servicios en el API para poder importar fácilmente todos los artículos, eventos, autores... de nuestro WordPress.
• Hemos modificado algunos servicios en el API para que solo muestre los registros visibles y con fecha de publicación pasada. También hemos creado otros nuevos para poder consultar los registros con fecha de publicación futura, para poderlos previsualizar.
• Creados campos específicos para el SEO.
• Añadir un módulo en el panel de administración para poder lanzar el proceso de compilación de la web cuando el editor desee.

Generador de estáticos

Si en cuanto a CMS había una gran variedad para escoger, con los generadores de estáticos hay todavía más opciones. Tambíen tenemos una web que nos va a ayudar a elegir el más idóneo para nuestro caso: staticgen.com

En este caso, valoramos más seriamente 3 opciones:

Gatsby

• Muy potente, pero no me gusta el código que genera.
• El resultado que genera es una single page app con React.

Esta es una opción muy potente, pero no me gustó para nuestro caso por los posibles problemas con el SEO y porque me gusta tener mucho control sobre el HTML que sirvo al cliente.

Jekyll

Es el más famoso del lugar, pero...

• Está desarrollado en Ruby, lenguaje con el que carezco de experiencia
• Especializado para consumir páginas de Git. Digo lo mismo que antes, para muchos casos es una opción muy interesante, sobre todo para la gestión de cambios, pero que personalmente prefiero seguir teniendo los datos en una base de datos más tradicional.

Eleventy

Para seleccionar un CMS dudamos más, pero para el generador de estáticos teníamos bastante claro desde un principio que el ganador sería 11ty, ya que no encontramos ningún riesgo aparente, pero sí muchas fortalezas:

• Sencillez de uso, pero potente.
• Control total sobre el código generado.
• 100% JavaScript.
• Buena documentación, y soporte muy rápido por parte de su creador (Zach Leatherman).
• Te da libertad para usar cualquier motor de plantillas. En nuestro caso usamos Nunjucks.

¿Cómo funciona Eleventy?

Lo primero que hace Eleventy ante un proceso de construcción es obtener los datos que posteriormente usará para pintar los HTML.

Esta información la busca en la carpeta _data. Cada fichero que encuentre dentro devolverá una colección de datos a la que se podrá hacer referencia en cualquier plantilla. En ese fichero se puede devolver un JSON directamente u obtenerlo haciendo una petición a un API, como se hace en este caso:

En este caso se hace una petición a Strapi para obtener todo el listado de ofertas de trabajo que mostramos en la web. Posteriormente, se parsea su contenido para cubrir las necesidades de visualización. Y finalmente se devuelve el resultado que guardará una variable jobs (nombre dado por el nombre del fichero) con el listado resultante.

Una vez que tenemos todos los datos necesarios, se empiezan a “pintar” cada una de las plantillas. Yo guardo todas dentro de la carpeta _pages para que estén más ordenadas, pero pueden estar donde se quiera. Cada fichero dentro de _pages acabará siendo un HTML (o varios en caso de haber paginación).

¿Qué entiende Eleventy por paginación?
Por ejemplo, un listado de artículo es paginación. Hasta ahí estaba muy claro para mí, pero la plantilla que pinta el detalle de cada una de esos artículos también es paginación, una paginación de 1 elemento por cada página.

Para que un fichero sea considerado plantilla, vamos, que acabe siendo un fichero en la construcción final, debe de tener es que tenga esta estructura:

---
permalink: /blog/index.html
title: Mi título de ejemplo
---
<h1>{{ title }}</h1>

Las variables que definimos en las primeras líneas, entre los símbolos de --- se denominan front matter, y podemos crear tantas como queramos para su posterior uso.

Eleventy permite hacer uso de layout base para poder ser extendidos por medio de bloques, donde inyectar el contenido propio de cada una de nuestras páginas y en ellas hacer uso de las colecciones de datos, filtros, e importaciones de otros ficheros. Todo ello explicado bastante bien en su documentación.

MicroApps

Por último, necesitábamos crear algunas pequeñas aplicaciones para dar dinamismo a algunas partes de nuestros HTML estáticos. Y las hemos desarrollado para cubrir justamente nuestras necesidades, ya que los productos disponibles en el mercado no nos encajaban del todo bien.

Comentarios

Crear, editar y listar los comentarios asociados a un artículo. Tiene su propia zona de administración donde validar o rechazar cada uno de los comentarios.

Búsquedas

Poder realizar búsquedas sobre el contenido de la web. Las consultas las hace sobre unos JSON que se generan desde Eleventy.

Encuestas

Crear, editar y mostrar las encuestas asociadas a un artículo. Y también tiene una zona de administración para crear estas encuestas.

Pues ya están todas las cartas sobre la mesa. Ahora ve llegando la hora de sacar conclusiones, y aprender para el futuro.

¿En qué hemos mejorado con el nuevo sistema?

Hemos ganado en todos estos puntos:

Sencillez

Ahora la administración es más sencilla, ya que evitamos todos los extras que te da Wordpress y que no se suelen usar.

Ser tonto mola

Al tener publicados solo HTML estáticos mejoramos la seguridad y la rapidez de respuesta es mucho mejor que antes.

Control sobre el dato

Ahora sentimos que tenemos mejor acceso a los datos y eso nos da facilidad para cambiar en el futuro. Al estar todo más desacoplado y más localizable, será mucho más sencillo hacer otra migración en el futuro a otro sistema, tanto de CMS como de generador de estáticos.

Estar a la última

Ahora molamos más. No nos engañemos, mola mucho decir que trabajas con las últimas tecnologías y ahora nosotros lo hacemos. Y dejamos atrás esa mala fama que siempre lleva WordPress consigo.

¿En qué hemos empeorado?

Seamos sinceros, no es oro todo lo que reluce y en algunos aspectos estabamos mejor antes del cambio:

Salir de la zona de confort da miedo y cuesta dinero. Hemos tardado mucho más tiempo para conseguir cosas que con Wordpress hubiesen sido más rápidas. Pero esto no es un punto en contra del nuevo sistema, simplemente es una consecuencia de cambiar de una tecnología que controlas a otra en la que eres novato.

WordPress lo usa todo el mundo y eso tiene sus problemas, pero también sus ventajas. Cualquier problema que te encontrabas con WordPress le había pasado a alguien antes y está documentada su solución en internet. Por lo tanto, ahora tenemos menos documentación a nuestra disposición.

Para llevar a cabo este nuevo modelo hace falta mucho más soporte del departamento de sistemas, ya que donde antes tenías un solo servidor ahora tienes tres. Además, tienen que comunicarse entre ellos y estar muy bien configurados. Esto es algo que no valoramos bien al principio del proyecto y ha sido de las partes que más problemas nos ha traído al final.

Y lo mismo que pasa con los servidores pasa con las aplicaciones, donde antes solo tenías que formarte en WordPress ahora debes controlar y gestionar varias aplicaciones. Eso sí, más sencillas cada una de ellas por separado.

Al grano... ¿volvería a usarlo?

Siento decepcionaros, pero no tengo una conclusión clara. En mi opinión la decisión final depende de factores como:

• El tiempo disponible. Para mí sigue siendo más rápido hacer una web con WordPress. Pero solventar esto es cuestión de seguir ganando experiencia.
• Perfiles asignados al proyecto. Tradicionalmente un proyecto de WordPress era llevado a cabo por un solo desarrollador, encargado de configurar el CMS y de maquetar el frontal. Este modelo para mí ya no es válido y debes disponer de un desarrollador para gestionar el CMS, al menos otro para la parte del frontal y otro para la gestión de los servidores.
• La necesidad de partes dinámicas. Los HTML tienen muchas ventajas, pero si tu proyecto va a tener muchas secciones dinámicas, en las que el usuario pueda interactuar, que se te enciendan las alarmas. Ya no dispones del abanico de plugins de WordPress y es posible que te los tengas que picar tú mismo.
• Y la implicación de sistemas. Ya lo he explicado antes, antes en un proyecto de WordPress la implicación de sistemas era mínima (bueno, salvo para la gestión de la seguridad), y con este nuevo sistema creo que deben de estar mucho más implicados.

Dicho todo esto, controlando todos estos problemas y olvidando estos seis meses de duro trabajo, sigo con ganas de perfeccionar más este modelo y seguir apostando por él en próximos proyecto.

¿Te animas tú también a probarlo?