Remixando WordPress: Construyendo un Sitio Headless con Remix, WPGraphQL y Fundamentos Web

¡Hola, React Summit! Mi nombre es Jeff Eberhardt, y soy un Senior Developer Advocate en WP Engine. El título de mi charla de hoy es Remixing WordPress, donde vamos a pasar unos 20 minutos construyendo un sitio headless con Remix, WP GraphQL, y algunos otros plugins open-source.

Pero antes de empezar, tal vez podríamos hablar en términos generales sobre qué es headless WordPress. Con el aumento de las arquitecturas JAMstack, vemos una gran cantidad de ofertas de SaaS en el espacio de los CMS headless. Pero si estás buscando una alternativa open-source, mucha gente no sabe que WordPress también puede convertirse en un CMS headless. Y con WordPress siendo el sistema de gestión de contenido más popular, que alimenta aproximadamente el 40% de la web en el momento de esta grabación, es probable que tus equipos de contenido ya estén familiarizados con la plataforma de WordPress. Así que puede haber muchas razones para considerar esto como una opción.

Entonces, tomemos un segundo y hablemos sobre lo que nos ofrece el WordPress tradicional. El WordPress tradicional es tu plataforma de software monolítica básica. El visitante interactúa tal vez con un CDN al escribir una URL en la barra de su navegador. En última instancia, todas esas solicitudes son atendidas por el núcleo de WordPress. Cualquier experiencia de desarrollo que necesite ocurrir, ya sea de temas o desarrollo de plugins, ocurre directamente con ese software del núcleo de WordPress, al igual que las interacciones de los editores. Cuando las personas están creando contenido, lo hacen como parte del monolito de WordPress.

Ahora, cuando comparamos el WordPress headless en comparación, eso le ofrece al desarrollador mucha flexibilidad. La experiencia para el visitante sigue siendo la misma. Escribe esta URL en la barra del navegador, pero en lugar de que su solicitud sea manejada por el núcleo de WordPress, en realidad es manejada por una aplicación que determinamos cómo se ve. En el ejemplo de hoy, vamos a usar Remix como este runtime de Node.js, pero eso podría ser cualquier framework front-end potencial, ya sea que te guste Nuxt o Next o quieras usar SvelteKit. Eso depende completamente de ti como desarrollador, y todo tu esfuerzo se centrará en desarrollar esa plataforma. Y todo eso interactúa con WordPress a través de las APIs REST o GraphQL que vamos a explorar hoy, que son parte del núcleo de WordPress o se agregan mediante plugins. Pero el beneficio final es que la experiencia para el editor o el creador de contenido no cambia, y pueden usar WordPress tal como está para crear contenido publicado, mientras nosotros, como desarrolladores, podemos aprovechar los beneficios que ocurren en el espacio de los frameworks front-end y llevar esos beneficios a nuestros usuarios.

Así que empecemos. No tenemos mucho tiempo, así que voy a empezar a construir nuestro sitio headless de inmediato. Lo primero que debemos hacer es crear un nuevo sitio de WordPress. Y voy a hacer eso usando las herramientas de desarrollo local. Hacer clic en crear nuevo sitio, darle un nombre a mi sitio, seleccionar la opción de personalización preferida, crear un nombre de usuario y contraseña de administrador, y luego permitir que local instale esos servicios en mi máquina local. Si ya tienes un sitio de WordPress, siéntete libre de usarlo también e instalar los plugins allí. Una vez que se haya completado la instalación, podemos abrir el panel de administración de WP, iniciar sesión y luego necesitaremos instalar algunos plugins. Primero, querremos instalar el plugin WP GraphQL, que básicamente convierte nuestro WordPress en una API WP GraphQL. Podemos instalar y activar ese plugin. Y también instalaremos un plugin llamado Atlas Content Modeler, que es un plugin de modelado de contenido enfocado en headless que nos permitirá crear tipos de contenido complejos y hacerlos disponibles inmediatamente a través de GraphQL.

Ahora, con nuestros plugins instalados, podemos trabajar en la creación de nuestro primer modelo de contenido. Para hacer eso, utilizaremos Atlas Content Modeler para crear un modelo de contenido relacionado con proyectos. Hacemos esto especificando un nombre singular y plural, determinando la visibilidad de la API de nuestro modelo de contenido, ya sea pública o privada, eligiendo un icono para la pantalla de edición posterior y creando una descripción para que nuestros usuarios la vean. Cuando hacemos clic en el botón de crear, eso generará automáticamente el modelo y comenzará el proceso de agregarlo a nuestra API de GraphQL.

Con nuestro modelo creado, podemos comenzar el proceso de agregar campos a nuestro modelo. Comenzaremos con un campo de texto que almacena el nombre del proyecto. Lo utilizaremos como título de entrada, lo haremos obligatorio y lo agregaremos a nuestro modelo. Después de eso, podemos agregar un modelo de fecha que almacenará la fecha de vencimiento del proyecto, hacerlo también obligatorio y agregar una descripción para ese modelo que se mostrará a nuestros usuarios. A partir de ahí, agregaremos un campo de texto adicional para almacenar el nombre del asignado al proyecto, y este será el asociado de DevRal asignado a un contenido específico. También lo haremos obligatorio, y luego agregaremos un último campo de texto enriquecido que será la descripción del proyecto.

Ahora que hemos creado nuestro modelo de contenido de proyecto, agreguemos algunos data. Abrimos la pantalla de edición posterior y completamos todos los campos que especificamos al crear el modelo, y luego, cuando hayamos terminado, podemos publicar esa pieza de contenido para que esté disponible para su uso en nuestra aplicación. Ahora que hemos agregado algunos data a nuestro proyecto, exploremos las características de WPGraphQL y el entorno de desarrollo gráfico. La función de composición de consultas del entorno de desarrollo gráfico nos permite explorar visualmente nuestro esquema GraphQL y seleccionar tipos de contenido individuales y sus nodos y propiedades, todo mientras componemos una consulta GraphQL que podemos ejecutar dinámicamente y que devuelve datos reales de nuestro sitio de WordPress. Ahora que entendemos los recursos disponibles en WordPress para modelar data y servir ese data a través de GraphQL, hablemos de cómo vamos a integrar Remix en esa ecuación.

Así que tengo una aplicación de Remix bastante básica configurada aquí con algunas dependencias instaladas que necesitaremos para comunicarnos con nuestro servidor de WordPress. Una de ellas es el paquete GraphQL. También he instalado Apollo Client. Y he hecho algunos estilos con Tailwind CSS.

Entonces, donde podemos comenzar es en nuestra ruta index.js. Aquí podemos ver que estamos importando dos componentes diferentes. Tenemos un encabezado básico y un componente de proyecto básico que enumerará nuestros proyectos en tarjetas en esta página.

Lo que haré aquí es en mi Terminal, simplemente hacer clic en NPM run dev para iniciar este servidor de desarrollo. Luego puedo volver aquí y simplemente actualizar en localhost 3000 y ver que esta matriz de datos de prueba, donde tengo algunos proyectos que eventualmente reemplazaremos con datos de nuestro sitio de WordPress, se está renderizando aquí para nosotros.

Lo siguiente que queremos hacer es configurar Apollo Client para consultar nuestro punto final GraphQL en nuestro sitio de WordPress. Para hacer eso, comenzaremos creando un archivo Apollo.js en la carpeta Lib. Luego agregaremos algunas declaraciones de importación para importar esos recursos necesarios de ese paquete. Luego, crearemos una exportación predeterminada que será nuestro cliente y lo estableceremos como nuevo Apollo Client. Luego pasaremos algunos parámetros de configuración. Una forma de obtener nuestro punto final GraphQL es volver a nuestro sitio de WordPress, abrir la página de Configuración de WP GraphQL y copiar y pegar eso en nuestro proyecto. Luego también crearemos una nueva caché en memoria que podemos usar para acelerar nuestra aplicación. Una vez que hayamos terminado, guardaremos esas cosas.

Ahora que hemos configurado Apollo Client, voy a crear un nuevo archivo para contener mi código de obtención de datos. Realmente, esta parte depende completamente de usted en cuanto a cómo desea estructurar o dónde desea que viva este código. Voy a crear un archivo llamado servicio de WordPress. Allí importaré el cliente que configuramos en el último paso y también el objeto GQL de Apollo Client. Luego crearemos una exportación y exportaremos una función llamada obtener proyectos. Luego, desde aquí, lo que haremos es volver a nuestra instancia WP GraphQL de WordPress, copiar la consulta que estábamos usando y luego crearemos una nueva consulta, abriremos una nueva plantilla literal con GQL y pegaremos esa consulta allí. Luego, lo que haremos es crear una nueva variable llamada respuesta y básicamente usaremos el cliente para consultar y pasar esa consulta a ese objeto de configuración. Y una vez que obtengamos esa respuesta de Apollo Client, profundizaremos en el objeto que obtenemos para devolver los nodos de proyecto individuales. Siempre es útil si no está seguro de cómo recorrer un objeto en particular, siempre puede volver a WP GraphQL y ver visualmente cómo se ve el data que obtendrá de esa llamada a la API.

OK, ahora que hemos desglosado esta función para hacer nuestra consulta GraphQL, hagamos una pausa por un segundo y hagamos un balance de dónde estamos. Vale la pena mencionar que aunque he creado este archivo de servicio de WordPress con estas funciones de exportación, cómo maneje la organización de este código de obtención de datos realmente depende completamente de usted. Sé que a muchos desarrolladores de React en particular les gusta la co-ubicación, por lo que tener el código que realiza la obtención de datos también dentro de sus componentes, hay formas de lograrlo también teniendo parte de este código en los archivos de ruta individuales. Esta es solo una elección que he hecho porque me gusta este patrón organizativo, pero eso no significa que no pueda tomar otra decisión, y Remix no tiene una opinión al respecto tampoco.

A medida que pasamos a ver cómo usamos esta función para cargar datos en nuestros componentes de ruta, Remix en realidad tiene una opinión, y hablaremos sobre algunas de esas diferencias. A continuación, echaremos un vistazo a este archivo index.jsx en nuestra carpeta de rutas. El framework Remix utiliza un sistema de enrutamiento basado en archivos, que es similar a lo que podrías encontrar en Next.js o Nuxt si vienes del mundo de Vue, por lo que hay una buena cantidad de superposición en cómo este framework maneja el enrutamiento. Y veremos algunos ejemplos más complejos en un momento.

Si abrimos nuestro archivo index.jsx, podemos ver que estamos importando algunos componentes aquí, y luego exportamos este componente de índice que devuelve todos estos elementos jsx que renderizarán nuestra aplicación. Pero en este momento, todos nuestros datos están codificados en la variable projects, por lo que el siguiente paso que abordaremos es cargar nuestros datos dinámicamente desde WordPress. Para lograr eso, simplemente agregaremos un par de declaraciones de importación aquí arriba, y los copiaré rápidamente desde fuera de la pantalla. Importaremos dos cosas diferentes. Entonces importaremos nuestra función getProjects desde este archivo de servicio de WordPress, y luego también importaremos este gancho de datos useLoader de Remix en sí mismo. Una vez que hayamos hecho eso, bajaremos aquí y crearemos otra exportación, y esta será una función asíncrona llamada loader, que es una convención de Remix. Lo que sucederá es que cuando Remix renderice tus componentes, llamará a lo que esté dentro de esta función loader en el servidor, y se conectará a tu servicio, sea cual sea, en nuestro caso WordPress y GraphQL, para obtener algunos datos, y luego podremos acceder a los datos que esta función loader devuelve utilizando el gancho de datos useLoader. Entonces, en este ejemplo, todo lo que necesitamos hacer es agregar una declaración de retorno, y luego esperaremos el resultado de getProjects. Nuevamente, esa es una de las razones por las que personalmente me gusta desarrollar de esta manera. Me gusta tener un archivo de servicio con todas mis diferentes llamadas de datos para que mis componentes de ruta puedan ser muy limpios. Alternativamente, podrías hacer parte de esto dentro de esta función loader. Eso depende completamente de ti y de cómo quieras manejarlo, y para ser honesto, no estoy seguro de si a Remix realmente le importa de todos modos. Entonces tenemos esta función loader, estamos haciendo algo de trabajo en ella, y depende de nosotros determinar qué es lo que queremos hacer. Y luego, lo que haremos aquí es en lugar de codificar en duro esta matriz, podemos usar el gancho de datos useLoader. Así que estableceremos projects igual al resultado de esta función useLoader, y si guardamos eso y actualizamos nuestra página aquí, podemos ver que boom, funcionó tal como esperábamos. Cuando se llama a esta ruta de índice, vamos a renderizar ese componente. Esta función loader llama a getProjects en el servidor, devolvemos esos datos, y luego usamos esos datos a través de este gancho para poblar estos componentes de proyecto aquí abajo. Así que fantástico, tenemos nuestra página de índice funcionando como queremos, pero creo que podría ser el momento de hacer una pausa por un segundo y discutir esta elección orientada que hace el framework Remix.

He trabajado en varios proyectos de Next.js y otros proyectos de React donde parte de la carga de datos que estamos haciendo ocurre completamente en el cliente. Y así que si estamos acostumbrados a usar el gancho useQuery de Apollo, por ejemplo, y hacer que esos componentes realicen esas llamadas a nuestro servidor GraphQL en el cliente, esto es un poco de cambio de paradigma, si quieres, ¿verdad?, porque cada una de estas funciones loader solo se llama en el servidor. Creo que el equipo de Remix tomó esa decisión por una muy buena razón, y han enumerado esas razones en muchos videos, así que no las repetiré, y te animo a que veas algunos de los sencillos de Remix para tener una buena idea de ellas. Pero de alguna manera, nos ayuda a los desarrolladores a simplificar el tipo de código que estamos escribiendo, ¿verdad? Si miramos un framework como Next.js, por ejemplo, donde tal vez estamos generando un sitio estático y luego algunas cosas se cargan en el cliente, tiende a volverse un poco desordenado, ¿verdad?, porque tenemos todas estas abstracciones diferentes para estos diferentes casos de uso, donde creo que Remix simplifica eso. Dice que esta es la única forma en que vamos a cargar datos en los componentes, por lo que eso lo hace un poco más fácil. También facilita un poco el manejo de credenciales, ¿verdad? Si estuviera realizando llamadas autenticadas a una base de datos, dado que todas estas llamadas de obtención de datos y la función loader ocurren en el servidor, no tengo que preocuparme por filtrar mis credenciales al cliente. Así que hay algunas ventajas en esto que definitivamente recomiendo que explores si eres nuevo en Remix y compares y contrastes con el framework que elijas en ese momento. Ahora que tenemos nuestra página de índice como queremos, cada uno de estos enlaces en realidad es un enlace a un proyecto individual.

En este momento, si hacemos clic en él, obtenemos un error 404. Por lo tanto, en los próximos minutos, profundizaremos un poco más y veremos cómo manejaríamos este ejemplo de enrutamiento dinámico con el framework Remix y WordPress.

Ok, para que nuestro proyecto maneje esta URL de ruta dinámica, necesitaremos hacer algunos cambios en nuestra carpeta de rutas. Podemos ver que la URL a la que estamos enviando la aplicación es project/slug del proyecto en particular. Por lo tanto, dentro de nuestra carpeta de rutas, crearemos una nueva carpeta llamada projects para que coincida con esa parte del segmento de URL. Luego, dentro de esa carpeta de projects, crearemos un nuevo archivo llamado $slug.jsx. Este será el componente que exportaremos. Así que voy a copiar esto rápidamente desde fuera de la pantalla y pegarlo aquí para que podamos echarle un vistazo. Guardaremos eso y luego hablaremos de algunas cosas diferentes aquí, y ya podemos ver en la terminal que tenemos trabajo que hacer. Volvamos, guardaré esto una vez más, volvamos a nuestro servicio de WordPress y sigamos desde allí.

Podemos ver que nuestro componente está utilizando esta función get project by slug, así que volvamos allí y la generaremos. En este momento, no devolverá nada, get project by slug y esto tomará el slug como parámetro. Ahora que lo hemos generado, volvamos a nuestra instancia de WordPress y aquí es donde usamos la interfaz gráfica para crear nuestra consulta GraphQL. Nuevamente, utilizando la interfaz gráfica en el generador de consultas, podemos usar esas herramientas para ayudarnos a crear y formatear visualmente una nueva consulta para obtener nuestra publicación por el slug. Si abrimos el nodo de proyecto individual dentro del generador de consultas, podemos usar eso y especificar el tipo de ID por el que queremos buscar la publicación. En este caso, usaremos slug y obtendremos un ID de nuestro sitio de WordPress y lo pasaremos, y luego agregaremos todos los campos adicionales que teníamos en nuestra consulta anterior para asegurarnos de que todos los datos sean los mismos. Podemos hacer clic en ellos para agregarlos a la consulta y una vez que hayamos terminado, podemos previsualizar el resultado de esa consulta ejecutándola en la interfaz gráfica. Y una vez que tengamos nuestro GraphQL formateado de la manera que queremos y nos aseguremos de que devuelva los datos que queremos, podemos copiarlo y pegarlo de nuevo en nuestro archivo de servicio de WordPress. Haremos algunos cambios dentro de esta plantilla GQL para parametrizar esta consulta para que podamos pasar el ID. Luego, después de eso, realizaremos la consulta con nuestro objeto cliente y pasaremos esa consulta formateada, así como una propiedad de variables que toma un objeto donde cada propiedad en ese objeto de variables, como ID por ejemplo, corresponde a una de las variables que parametrizamos en la plantilla literal de etiqueta. Luego, también recorreremos nuestra respuesta de GraphQL y la devolveremos a nuestra función loader. Y como siempre, si estás confundido y necesitas ayuda para saber cómo se ve tu data, siempre puedes usar la interfaz gráfica para explorar eso.

Vale la pena hablar rápidamente sobre la función loader tal como se implementa en el archivo slug.jsx. Gran parte de esto debería parecer muy familiar a lo que hicimos en nuestro archivo de índice, con la excepción de este objeto params que se pasa al loader. Así es como accedemos a esos componentes de URL dinámicos. Entonces, dollar sign slug se convierte en params.slug y luego lo pasamos a nuestra función get project by slug que importamos desde nuestro servicio de WordPress. Y si venimos aquí y actualizamos nuestra página, verán que todo funciona como esperamos, y ahora tenemos tanto una página de índice como segmentos de URL dinámicos que buscan publicaciones individuales.

Gracias por asistir a mi charla sobre Remix y WordPress sin cabeza. Si estás interesado en aprender más sobre la alternativa de CMS sin cabeza y algunos de tus frameworks front-end favoritos, asegúrate de seguirme en Twitter o consultar algunos de los contenidos en developers.wpengine.com. Gracias.