CMS sin cabeza: Gatsby JS con WordPress

Es bien sabido que WordPress cubre aproximadamente un tercio del millón de sitios web más importantes del mundo con más del 50 % de participación de mercado en sistemas de administración de contenido. Recientemente, en 2016, WordPress decidió introducir una API REST para proporcionar a otras aplicaciones un mejor acceso al contenido de la base de datos de WordPress. Como resultado, brinda a los desarrolladores la capacidad de aprovechar WordPress como un CMS sin cabeza.

Esto implicaba inevitablemente que los ingenieros ya no estarían limitados a emplear la capa de presentación convencional (frontend) de WordPress, sino que ahora podrían explotar cualquier aplicación frontend para entregar sus datos. A la luz de esto, la mayor parte de este blog explorará la relación de WordPress y Gatsby.js con respecto a la ejecución de Headless CMS.

Una breve historia de CMS

A medida que damos un paso atrás para comprender la revolución Headless CMS, creo que vale la pena recapitular la historia de los sistemas de administración de contenido (CMS). Tradicionalmente, a principios de los 90, las páginas web estáticas eran la forma principal de ejecutar sitios web en los que un webmaster editaba directamente archivos HTML y los subía a un servidor a través de FTP. Eventualmente, a mediados de los años 90, la tecnología web comenzó a evolucionar y el contenido se volvió más dinámico, lo que llevó a la aparición de los primeros sistemas de administración de contenido monolítico.

Esencialmente, un CMS monolítico es una aplicación de software que incluye todo lo necesario para editar y publicar contenido en la web. El primero de estos sistemas estaba limitado a empresas como EpiServer, sin embargo, más tarde aparecieron variaciones de código abierto como WordPress, Drupal y Joomla. El resto es historia, ya que WordPress ganó la mayor cuota de mercado con el tiempo.

Sin embargo, más tarde, durante la revolución de los teléfonos inteligentes, los dispositivos móviles comenzaron a afectar la forma en que se consumía y entregaba el contenido web. Este fue un desafío para los CMS monolíticos tradicionales diseñados para entregar contenido web para computadoras portátiles y de escritorio.

Para mitigar esto, nació el diseño receptivo que resultó en diseños de sitios web que se adaptaban al tamaño de la pantalla. En consecuencia, esto también brindó la oportunidad de desacoplar la gestión de contenido de la capa de visualización. Aquí es donde entran nuestros CMS sin cabeza.

CMS sin cabeza

Como se mencionó anteriormente, un CMS Headless es uno sin una capa de presentación. Como resultado, el contenido se entrega a través de una API (RESTful o GraphQL) para separar la aplicación de interfaz que luego lo presenta. La API pone el contenido a disposición de cualquier canal y dispositivo utilizando una variedad de herramientas y lenguajes de programación con un mayor nivel de seguridad y escalabilidad.

Esencialmente, el CMS está desvinculado de las preocupaciones de la interfaz, lo que a su vez libera a los desarrolladores para crear experiencias ricas para los usuarios finales, utilizando la mejor tecnología disponible. Actualmente, la mayoría de los CMS admiten un modo "sin cabeza" o "desacoplado", lo que allanó el camino para los sitios de Gatsby.

Por lo tanto, para aprovechar un CMS sin encabezado, primero deberá crear su sitio o aplicación y luego usar la API del CMS para conectar su contenido.

La ejecución de WordPress Headless CMS

Con respecto a la cronología de los eventos compartidos anteriormente, hemos visto cómo WordPress terminó realizando un CMS sin cabeza. WordPress contiene una API (interfaz de programación de aplicaciones) que le permite ampliarla con complementos (esencialmente como un "marco de aplicaciones"). En particular, esto se logra a través de la API REST, como veremos más adelante.

Sin embargo, uno de los conceptos clave de la API de WordPress son los ganchos. Básicamente, los ganchos permiten que los complementos cambien la funcionalidad principal de WordPress. En la práctica, los Hooks funcionan de manera que cuando ocurre un determinado evento en WordPress (por ejemplo, la carga de una página o la post-edición), WordPress llama a un determinado hook para ejecutar la función.

Específicamente, los ganchos se dividen en 'Acciones' y 'Filtros'. Las acciones se pueden aprovechar para ejecutar ciertas funciones de PHP en ciertos eventos, aunque las funciones no necesitan devolver nada. Si bien los filtros se pueden utilizar para ejecutar funciones a través de las cuales WordPress pasa datos durante ciertos eventos, estas funciones toman datos como un parámetro y devuelven una versión modificada de los datos.

WordPress y la API REST

La transferencia de estado representacional (REST) ​​se basa en el protocolo HTTP y proporciona una semántica de interfaz uniforme para crear, leer, actualizar y eliminar datos (CRUD).

En general, la ejecución de la API REST en WordPress permite a los desarrolladores acceder a datos en una base de datos de WordPress de forma remota mediante el envío y la recepción de objetos JSON (notación de objetos de JavaScript). En consecuencia, esto brinda a los desarrolladores la oportunidad de crear, leer, actualizar y eliminar datos de WordPress de otras aplicaciones que no están diseñadas con WordPress. Por ejemplo, aplicaciones web de JavaScript o aplicaciones móviles nativas.

Sin embargo, a medida que profundizamos en la comprensión de la relación de Headless WordPress CMS con las API REST y Gatsby, debemos tener en cuenta algunos conceptos fundamentales de la API de WordPress:

• Rutas y puntos finales: las rutas son rutas a las que puede acceder a través de una llamada HTTP, mientras que un punto final es un método HTTP (como obtener, publicar, colocar o eliminar) asignado a esa ruta.
• Solicitud: cuando inicia una solicitud HTTP a una ruta REST registrada, WordPress creará automáticamente un objeto de solicitud. Los datos que se especifican en la solicitud determinarán qué respuesta obtendrá.
• Respuesta: un objeto de respuesta son los datos que recibe cuando realiza una solicitud. Puede incluir datos solicitados o mensajes de error.
• Esquema: Un esquema se refiere a la estructura de datos en el punto final. Cada punto final puede tener una estructura de datos leve o significativamente diferente que puede devolver. En consecuencia, un esquema determinará todas las propiedades posibles que puede devolver un punto final y todos los parámetros posibles que puede recibir.
• Clases de controlador: las clases de controlador permiten a los desarrolladores administrar y registrar puntos finales y rutas, al mismo tiempo que les permite manejar solicitudes, utilizar esquemas y generar respuestas.

El 'Marco' de React

A medida que nos adentramos en el meollo de la relación de Gatsby.js y WordPress, para obtener más contexto, tenemos que descifrar este panorama tecnológico a partir de bases más históricas. React es clave para esta historia, ya que es la biblioteca/marco de frontend de JavaScript de más rápido crecimiento. Hecho famoso por Facebook (sus principales desarrolladores), otros grandes sitios web utilizan React para su interfaz como: Airbnb, Netflix, Dropbox, BBC, PayPal, Reddit, Salesforce, Squarespace y Tesla.

En consecuencia, dado que React es una biblioteca en la práctica (ya que aún carece de las características notables de un marco completo), esto significa que se pueden diseñar otros "marcos" encima de él. Como resultado, uno de estos es Gatsby.js.

Presentando a Gatsby

Según su sitio web principal, Gatsby.js es un marco JavaScript gratuito y de código abierto basado en React que ayuda a los desarrolladores a crear sitios web y aplicaciones rápidos. En principio, Gatsby.js genera páginas HTML estáticas a partir de aplicaciones para la carga inicial y luego procede como una aplicación React (SPA) de una sola página.

Atributos de Gatsby.js

En esas circunstancias, Gatsby explota los principios de la aplicación web progresiva (PWA) para obtener primero solo los elementos necesarios y luego carga el resto de la aplicación en segundo plano. Además, para garantizar que solo se carguen los datos necesarios, Gatsby aprovecha el lenguaje de consulta GraphQL (también de Facebook) para cargar los datos desde la fuente. También mantiene una optimización de imagen excepcional.

Todas estas capacidades combinadas brindan a los desarrolladores las herramientas necesarias para crear los sitios web y las aplicaciones web más rápidos posibles, ya que solo carga HTML, CSS, datos y JavaScript críticos. Entonces, una vez que se carga una página, Gatsby obtiene recursos para las páginas vinculadas y, por lo tanto, navegar por el sitio se siente bastante rápido.

Además, dado que las páginas se generan en la compilación, antes de la colocación en línea, ya no necesita servidores PHP potentes y puede servir archivos estáticos (HTML, JS y CSS, directamente desde el almacenamiento del depósito). Además, dado que Gatsby funciona con React, podrá estructurar todo muy bien con componentes. Este aspecto modular permite a los desarrolladores reutilizar fácilmente los componentes.

Otras características significativas listas para usar de Gatsby incluyen:

• Generador de sitios estáticos
• Acceso sin conexión
• Obtención previa de páginas vinculadas
• Caché de página
• Sin búsqueda de código extraño
• Exportar como código
• Contenido de recarga caliente
• Código de recarga en caliente
• Componentización
• Enlace de datos unidireccional
• Consultas de datos API declarativas (GraphQL)
• IU declarativa
• Carga progresiva de imágenes
• Carga de imagen sensible
• Integración del CSS crítico
• Autohospedaje de fuentes
• sin servidor
• Canalizaciones de activos
• Extensiones CSS (SaSS)
• Sintaxis avanzada de JavaScript
• Reaccionar ecosistema de componentes

Complementos de Gatsby

Esencialmente, los complementos de Gatsby son fundamentalmente paquetes de Node.js que utilizan la API de Gatsby. Estos complementos pueden agregar fuentes de datos, transformar datos a otros formatos y agregar servicios de terceros. Aunque Gatsby.org mantiene una biblioteca de complementos que incluye muchos complementos ya creados por el equipo central de Gatsby o por terceros. Idealmente, para instalar un complemento para un proyecto de Gatsby, los desarrolladores emplean el administrador de paquetes de nodos (NPM) en su terminal UNIX y ejecutan el comando npm install.

Cómo se relaciona GraphQL Comes con Gatsby.

GraphQL gira en torno a la idea de que puede describir a la API exactamente los datos que desea, y recibirá exactamente eso. Como resultado, es más eficiente que REST. Con este fin, Gatsby emplea Webpack y GraphQL. Más importante aún, con GraphQL como lenguaje de consulta, todo se define del lado del cliente que ejecuta la consulta, sin que el cliente se dé cuenta del funcionamiento insuficiente de la aplicación.

Esta implementación única permite a los desarrolladores conectar cualquier fuente de datos a Gatsby. Por ejemplo, las publicaciones de blog pueden provenir de archivos Markdown, hojas de cálculo de Google o incluso de otro sitio web de WordPress. Por lo tanto, proporciona una mayor flexibilidad con la entrega de contenido.

Mecanismo de Gatsby-WordPress (complementos de origen)

A medida que profundizamos en esta relación, debemos comprender los complementos de origen. Los complementos de origen son complementos especiales que funcionan dentro del sistema de datos de Gatsby. Como su nombre ya lo indica, obtienen datos de diferentes ubicaciones, ya sean locales o remotas. En consecuencia, los datos se convierten en lo que Gatsby denomina nodos y campos de nodos. Básicamente, los campos de nodo representan una sola pieza de datos dentro de un nodo y, en última instancia, se puede acceder a estos nodos a través de una consulta de GraphQL.

De la misma manera, a través de los complementos de origen, Gatsby admite docenas de opciones de CMS sin cabeza, lo que brinda a los equipos de ingeniería y contenido la comodidad y la familiaridad de su interfaz de administración preferida con la experiencia mejorada del desarrollador y los beneficios de rendimiento de usar Gatsby, GraphQL y React para crear un Interfaz.

El complemento 'Gatsby-source-WordPress' está creado y mantenido por el equipo central de Gatsby, y extrae datos de sitios de WordPress autohospedados o de WordPress.com. También implica la autenticación OAuth para la API de Word-Press.com y también permite a los desarrolladores consultar imágenes receptivas.

Esencialmente, este complemento admite todas las entidades en la API REST de WordPress, como publicaciones, páginas, etiquetas, categorías, medios, tipos, usuarios, estados, taxonomías, metadatos del sitio y tipos de publicaciones personalizadas. Además, también se admiten las entidades de campos personalizados avanzados (ACF) y la información de lenguaje Polylang y WPML, además de otras publicaciones meta registradas en la API REST.

Entonces, con este complemento, los desarrolladores pueden elegir qué rutas buscar, aunque obtiene todos los puntos finales de wpjson de forma predeterminada. Entonces, los desarrolladores pueden obtener datos de WordPress con GraphQL empleando el mecanismo anterior.

En la práctica, la herramienta 'Gatsby-source-WordPress' proporciona un slug para todas las publicaciones y otras entidades. Y, por lo tanto, todo lo que un ingeniero debe hacer es crear una página que llame a la función 'createPage'. Esto se ejecuta en el archivo Gatsby-node.js, normalmente ejecutando primero una consulta para la fuente de datos y luego llamando a 'createPage' para cada nodo encontrado, luego configurando un archivo de plantilla para usar como componente.

CI/CD y Automatización de lanzamiento de aplicaciones.

Al implementar un CMS de WordPress sin cabeza con Gatsby, la forma en que se realiza la implementación es muy crítica. Por lo general, dichas ejecuciones requieren que la implementación de una aplicación se automatice utilizando la Automatización de lanzamiento de aplicaciones (ARA).

Generalmente, ARA implica funciones primarias:

• Despliegue de datos, código de aplicación y artefactos.
• Despliegue de configuraciones específicas para cada entorno
• Diseño de flujo de trabajo de procesos para tareas de automatización y pasos de implementación.
• Por último, modelado de entornos y/o binarios de aprovisionamiento.

Dado que Gatsby produce sitios estáticos, es imperativo configurar una tubería ARA para que cuando el contenido se actualice en WordPress, se pueda actualizar correspondientemente en el sitio de Gatsby. Por lo general, la implementación continua se activa solo cuando cambia el código; sin embargo, para esta instancia, es deseable activarla cuando cambian los datos. Entonces, para esto, recomendamos usar Netlify ya que posee impresionantes capacidades de implementación continua incorporadas y es fácil de configurar.

Consultando desde WordPress usando GraphQL y gatsby-source-WordPress

Como ilustración, gatsby-source-WordPress funciona de manera que primero obtendrá todo en su punto final usando REST. Luego generará una API GraphQl interna basada en esos datos. Posteriormente, revisará sus consultas y recopilará los datos de esa API GraphQL interna. Entonces, básicamente, su compilación solo termina con los datos que solicitó y nada más.

Ventajas del desarrollo Headless WordPress con Gatsby.js

Ya que hemos abordado el desarrollo de Headless WordPress con Gatsby, ahora podemos desglosar las ventajas de este tipo de enfoque técnico. ¡Esencialmente, esto debería guiar su decisión sobre si adoptar a Gatsby o no!

• El primer beneficio es la capacidad de tener un sitio estático y renderizado previamente. Esta es la forma más eficiente de representar una página web, y dado que Gatsby emplea GraphQL para ejecutar la cantidad mínima de datos necesarios, esto proporciona una eficiencia adicional para el tiempo posterior a la carga inicial.
• Visibilidad SEO mejorada: las páginas estáticas son fáciles de leer para los motores de búsqueda, ya que todo está renderizado previamente y es indexable. Esto es positivo, en contraste con otros mecanismos sin cabeza en los que la representación de páginas con JavaScript es un problema relacionado con la optimización de motores de búsqueda (SEO).
• Velocidad de desarrollo relativamente rápida: en comparación con otros enfoques sin cabeza, Gatsby tiene una forma unificada y fácil de entender de obtener datos, independientemente de la fuente. Esto simplifica bastante el desarrollo, ya que puede concentrarse en su sitio real y dejar que Gatsby haga la mayor parte del trabajo pesado.
• Alojamiento más económico: puede alojar su aplicación Gatsby en cualquier lugar, ya que solo sirve archivos estáticos, lo que reduce los gastos de alojamiento. Además, dado que WordPress solo se llama durante el proceso de creación y nunca durante la sesión del usuario, también se puede alojar en una solución de alojamiento asequible.
• Seguridad mejorada: en términos generales, los generadores de sitios estáticos son tremendamente seguros ya que no hay conexión directa a una base de datos, dependencias, datos de usuario u otra información confidencial.
• Sin complementos: desde la perspectiva de un no desarrollador, WordPress es bastante fácil de operar debido a los complementos disponibles. Sin embargo, esto restringe la implementación de funcionalidades personalizadas. Desafortunadamente, demasiados complementos también pueden ralentizar un sitio a medida que se vuelve pesado y más difícil de renderizar. Una ejecución de Gatsby evita esencialmente todos estos cuellos de botella.

Más facetas que pueden motivarte a considerar Gatsby con WordPress:

• Panel de administración de WordPress fácil de administrar.
• Sistema de inicio de sesión de usuario listo para usar y autorización.
• Con el editor de Gatsby y Gutenberg, puede crear un creador de sitios de Gatsby de arrastrar y soltar.

Desventajas del desarrollo Headless WordPress con Gatsby.js

• Limitaciones de actualización: cuando el contenido cambia desde cero, establece restricciones sobre la frecuencia con la que su sitio puede actualizarse. Además, puede tomar hasta 10 minutos ejecutar la compilación de Gatsby si su sitio contiene una gran cantidad de datos, lo que puede ser un problema para los sitios que se actualizan con frecuencia.
• Actualizaciones periódicas Hustles: Además, dado que Gatsby es un generador de sitios estáticos, no se puede simplemente "editar", ya que incluso un pequeño cambio de texto requerirá una nueva implementación. Por lo tanto, si tiene una página que requiere muchos cambios dinámicos de contenido diarios, esto puede llevar mucho tiempo y ser un ajetreo.
• Retrasos: por lo general, debe esperar varios minutos para ver los cambios en su contenido a medida que se publican.
• Falta de vistas previas: a diferencia de las aplicaciones tradicionales de WordPress, no tienes ningún tipo de vista previa en Gatsby. Lamentablemente, este ha sido el mayor problema que los creadores de contenido han encontrado con Gatsby. Deberá compilar todo, probablemente con canalizaciones de CI/CD de Gitlab que compilan el sitio web y ponen todo en línea.
• Curva de aprendizaje pronunciada: en general, si desea trabajar con Gatsby y WordPress al mismo tiempo, debe estar relativamente familiarizado con los lenguajes PHP y JavaScript. Dado que Gatsby fusiona React y GraphQL, esta puede ser una curva de aprendizaje empinada para muchos.

Pensamientos finales.

En conclusión, gracias a su rendimiento y ventajas comerciales, más empresas están implementando Gatsby como parte de su pila tecnológica. Aunque es importante recordar que al fusionar Gatsby con WordPress, WP se vuelve solo backend, lo que implica que perderá algunas de sus funcionalidades y habilidades.

Además, los desarrolladores experimentados con el desarrollo de WordPress encontrarán en Gatsby una gran herramienta con sus beneficios de rendimiento moderno, escalabilidad, seguridad y velocidad de desarrollo. Todo esto mientras les permite conservar la interfaz de usuario familiar de creación de contenido que ofrece WordPress.

Sin embargo, antes de iniciar esta tecnología, uno siempre debe considerar las especificaciones y objetivos de su proyecto. Por ejemplo, si el énfasis está en la escalabilidad, el rendimiento, la velocidad de desarrollo, el largo ciclo de vida, Gatsby servirá. Sin embargo, si el énfasis es tener una mayor flexibilidad y herramientas para los creadores de contenido que no son programadores con contenido actualizado cada segundo o minuto, entonces puede considerar un enfoque alternativo.