DE{CODE}: Headless 101 para desarrolladores de WordPress

El desarrollo sin cabeza puede ser más poderoso e incluso más divertido que el desarrollo tradicional de WordPress. Sin embargo, con tantas opciones nuevas en esta pila emergente, ¿cuál es la mejor manera de comenzar? Este taller guiará a los desarrolladores a través de la instalación y optimización de un proyecto de WordPress para headless, todo el camino hasta la plantilla de su primera página en una interfaz desacoplada.

Diapositivas de la sesión

Transcripción de texto completo

GRACE ERIXON : Bienvenido a Headless 101 para desarrolladores de WordPress. Mi nombre es Grace Erixon y soy defensora asociada de desarrolladores aquí en WP Engine. Me acompaña Steve de Haus. Hoy, le daremos una introducción rápida a lo que es WordPress sin cabeza y cómo puede comenzar a usarlo.

Entonces, para comprender qué es la arquitectura de un sitio web de WordPress sin cabeza, es importante asegurarse de que todos estemos en la misma página sobre cómo se ve una arquitectura tradicional de WordPress. Tradicionalmente, un CMS como WordPress manejaría tanto el front-end como el back-end de un sitio web.

En una arquitectura tradicional, el editor crea y administra contenido como publicaciones de blog y páginas dentro de WordPress. El desarrollador escribe código para controlar cómo se ve y funciona el sitio usando PHP y la API de temas de WordPress. Luego, WordPress genera la página HTML que se envía al visitante.

En esta arquitectura de CMS acoplada, WordPress proporciona las capacidades de gestión de contenido a los editores. Y también es responsable de servir páginas HTML a los visitantes del sitio web. Un CMS sin cabeza utiliza una arquitectura desacoplada en la que el front-end y el back-end se administran por separado. En una arquitectura sin cabeza, el editor aún crea y administra contenido en WordPress, al igual que en una arquitectura tradicional de WordPress.

El desarrollador escribe código para controlar cómo se ve y funciona el sitio en JavaScript, además de usar WPGraphQL o la API REST para extraer datos de WordPress. A menudo se utiliza un marco como Faust.js, Next.js, Nuxt.js o SvelteKit para potenciar esta aplicación de interfaz. Luego, la aplicación de JavaScript front-end genera y sirve las páginas HTML que se envían al visitante del sitio web.

A diferencia de una arquitectura tradicional, WordPress ya no es responsable de generar páginas HTML. Entonces, la interacción para intercambiar contenido entre el back-end de WordPress y la aplicación de JavaScript del front-end ocurre a través de la capa API. Las dos opciones para la capa API son la API REST de WordPress o WPGraphQL.

La API REST viene incluida con WordPress. Sin embargo, el patrón de acceso a datos que requiere puede ser lento porque REST requiere que cada recurso tenga su propio punto final. Por ejemplo, se requerirían múltiples viajes de ida y vuelta para reconstruir una publicación completamente modelada. Si quisiera obtener el contenido, el autor y la categoría de una publicación, necesitaría tres llamadas API separadas.

Por el contrario, WPGraphQL nos permite solicitar el contenido, el autor y la categoría de una publicación, todo en una sola solicitud. Debido a esto, WPGraphQL es nuestra capa de API preferida. WPGraphQL es un complemento gratuito que proporciona un esquema GraphQL extensible y una API para su sitio de WordPress. WPGraphQL es más rápido que la API REST porque obtiene los datos exactos que se solicitan y da como resultado que se ejecuten menos funciones a través de la optimización de consultas, se descarguen menos datos, se carguen datos de manera más eficiente y se incluyan múltiples recursos en una sola solicitud.

Una arquitectura sin cabeza brinda a los desarrolladores la libertad de elegir entre cualquier pila de tecnología front-end, siendo los marcos de JavaScript los más populares. Algunos de los marcos de JavaScript front-end más populares incluyen React, Vue.js y Svelte. Se lanzan nuevos marcos todo el tiempo, por lo que esta lista no es exhaustiva.

Muchos de estos marcos de JavaScript se usan junto con meta marcos que agregan soluciones para cosas como el enrutamiento, la representación del lado del servidor y más. React se usa junto con Next.js, Vue.js se usa junto con Nuxt.js y Svelte se usa junto con SvelteKit. Gatsby es otro meta framework popular.

WP Engine ha desarrollado Faust.js, un marco de JavaScript construido sobre React y Next.js. Faust se creó específicamente para admitir aplicaciones web de WordPress sin cabeza. Es compatible con la autenticación y las vistas previas de publicaciones listas para usar, proporciona convenientes ganchos React incorporados para acceder a los datos de WordPress y más.

Entonces, hemos hablado sobre lo que significa una arquitectura de WordPress sin cabeza y los tipos de tecnología que usaría. Pero analicemos rápidamente por qué elegiría incluso sin cabeza. WordPress en sí mismo es un CMS pesado y usa PHP, que no es un lenguaje rápido. Headless WordPress utiliza lenguajes de crianza a través de JavaScript y carga solo los archivos necesarios a través de llamadas a la API. Es mucho más liviano, por lo que su sitio se cargará más rápido.

WordPress sin cabeza también minimiza el riesgo para su contenido, ya que sus datos viven separados de su entrega frontal. Está menos expuesto a ataques web. Y el principal beneficio es que la arquitectura de WordPress sin cabeza permite a los editores continuar beneficiándose de la gran experiencia de publicación que brinda WordPress, al mismo tiempo que permite a los desarrolladores y visitantes del sitio web aprovechar las capacidades técnicas que las aplicaciones modernas de JavaScript aportan.

Ahora, profundicemos en el código de un sitio real sin cabeza. He pregrabado un tutorial del nuevo sitio de WordPress sin cabeza de Atlas Blueprints. La nueva función Blueprints en Atlas proporciona una manera realmente fácil de poner en marcha un sitio completo de WordPress sin cabeza. Vienen con código de inicio, complementos, modelos de contenido y estructura de página para que su aplicación despegue más rápido.

Entonces, creemos un nuevo sitio de Blueprint para que podamos sumergirnos en el código. Desde el interior del tablero de WP Engine, iremos a Atlas. Haga clic en Crear aplicación. Seleccione Comenzar con Blueprint. Y luego vamos a seleccionar qué modelo queremos usar. Voy a elegir el modelo de cartera.

Luego, conectará su cuenta de WP Engine a su cuenta de GitHub y clonará ese plano en un nuevo repositorio. Esto tomará un par de segundos para construir. Finalmente, simplemente seleccione el nombre del repositorio que acaba de crear, la región más cercana a la que se encuentra y luego haga clic en Crear aplicación.

Ahora, si hace clic en la URL de Atlas, podemos ver cómo se ve nuestro sitio de WordPress sin cabeza. Estamos específicamente interesados ​​en la página Publicaciones. Como puede ver, el sitio está incorporando todas las publicaciones más recientes en esta página Nuestro blog. Y cada publicación también tiene su propia página de visualización individual. Pero, ¿de dónde provienen todos estos datos?

Si volvemos al panel de WP Engine, veremos un botón para WP Admin. Ahí está el back-end de nuestro sitio de WordPress sin cabeza. Si hago clic en Publicaciones, verá la misma lista que la aplicación web. Ahora, podemos abrir el repositorio de GitHub en el que se clonó nuestro Blueprint. Y clonemos ese repositorio en nuestro entorno local.

Luego, abriré este repositorio en Visual Studio Code, mi editor de código favorito. Al profundizar en el directorio del proyecto, el archivo de la página del blog se puede encontrar en SRC, páginas, publicaciones, Index.js. Este proyecto está construido usando React, Next.js, Faust.js y WPGraphQL. Si no está familiarizado con React o incluso con JavaScript, esto podría parecer confuso al principio.

En la primera sección, el archivo solo importa cosas que necesita de fuentes internas y externas. La segunda sección que define los campos de prepaso de los nodos posteriores es donde se enumeran todos los datos que necesitamos. Ejecutar esto a través del paso previo garantiza que los datos estén allí cuando los necesitemos y que no se produzcan solicitudes en cascada.

Luego tenemos la función de página. Al principio, solo recopila los datos que necesitamos en algunas variables diferentes, a saber, la configuración general y una lista paginada de publicaciones. Las etiquetas dentro de la declaración de devolución es el código que se representará visualmente en la página web. Primero, tenemos el componente para el encabezado. Luego, dentro de este componente principal, tenemos un componente de encabezado de entrada, y eso es lo que muestra el título grande que dice Últimas publicaciones en la parte superior de la página.

Finalmente, llegamos al componente de publicación, que acepta la lista paginada de publicaciones como parámetro. Veamos qué hace el componente de publicación con esta información. Aquí está recorriendo cada publicación contenida en la lista de publicaciones que recibió. Para cada publicación, muestra la vista similar a una tarjeta en la página de la última publicación. Este primero consta de un componente de imagen destacada envuelto en un enlace a la página de la publicación de blog individual, un encabezado del título de la publicación y un componente de información de la publicación que consiste en la fecha y el autor de la publicación.

Volviendo al archivo Index.js que muestra todas las publicaciones, terminamos mostrando el componente Cargar más en la parte inferior de la página para recuperar más publicaciones si se solicita y un pie de página. La última función, getStaticProps, es una función de generación de sitios estáticos de Next.js que le indica que renderice previamente esta página en el momento de la compilación usando los accesorios devueltos por la función. Y eso es.

Gracias a Blueprints por manejar la configuración de Headless por nosotros. Fue sencillo desglosar lo que se incluye en la página de publicación para obtener datos del backend de WordPress usando WPGraphQL y mostrar las publicaciones usando componentes de React. Gracias por sintonizarnos. Puedes encontrarme en Twitter @graceerixon.

Visite developer.wpengine.com para obtener más contenido sobre Headless WordPress. Tenemos un tutorial sobre cómo crear su primer sitio Headless WordPress desde cero usando Faust.js, y estamos trabajando en una serie de contenido Headless 101 en este momento. Puede obtener todas las herramientas que ofrece Atlas si se registra para obtener una cuenta gratuita de Sandbox. Ahora se lo paso a Steve para que hable más sobre por qué Haus eligió Headless WordPress para su proyecto leoburnett.com.

STEVE SCAVO: Gracias, Grace. Hola, soy Steve Scavo, CTO de Haus. Somos un estudio y una agencia de tecnología creativa con sede en Los Ángeles, California. Esta charla se titula apropiadamente Headless 101 para desarrolladores de WordPress. Y sinceramente, no soy un desarrollador de WordPress de oficio, pero creo que eso es parte de la belleza de una arquitectura sin cabeza.

Así que fácilmente podríamos haber llamado a este Headless 101 para desarrolladores que no son de WordPress que necesitan aprovechar WordPress. Ese podría haber sido un título tan apropiado. Eso es lo hermoso de sin cabeza. Es un ganar-ganar de todos los lados, como verá.

Entonces, ¿por qué sin cabeza? Hay tantas razones de alto nivel de las que podríamos hablar, pero creo que hablar de ejemplos reales de producción y ejemplos del mundo real de cuándo brilla es realmente útil. Y me gustaría mostrar un proyecto que hicimos para Leo Burnett usando sin cabeza bajo una arquitectura sin cabeza. Por contexto, Leo Burnett es una agencia de publicidad histórica de Chicago, pero tiene muchas oficinas en todo el mundo y en todo el mundo. Entonces tienen mucho contenido, mucho trabajo.

El sitio anterior funcionaba con un solo tema de WordPress. Estaba realmente fragmentado, un poco lento, no funcionó bien. Fue difícil de actualizar y no exhibió el tipo de caché y la marca que Leo Burnett quería transmitir. Así que eso es con lo que nos pusimos a trabajar desde una perspectiva de diseño. Y elegimos headless para realmente modernizar su stack.

Solo queríamos que se sintiera vivo y fresco y que tuviera ese tipo de capacidad que necesitamos para crear una experiencia de usuario y una interfaz de usuario maravillosas. Queríamos aumentar su poder de publicación. Queríamos aumentar la cadencia por la cual pueden publicar contenido. Queríamos restablecer la identidad de la marca y tener una interfaz de usuario y una interacción, la sensación del sitio web que realmente exudaba Leo Burnett y todos estos pequeños toques y puntos editoriales, tipográficos y de interacción que querían transmitir.

Y queríamos preparar el código base y el sitio web para el futuro. No solo queríamos que el sitio fuera relevante durante los próximos 12 meses. Queremos que sea relevante para la próxima década, tal vez. Y creo que esta arquitectura sin cabeza, esta pila sin cabeza realmente hace eso.

Entonces, uno de los problemas iniciales con headless es que siempre hay muchas decisiones sobre el alojamiento, la implementación y la infraestructura, y siempre ha sido un gran problema. Por lo tanto, estas decisiones de pila siempre se han dejado en manos del desarrollador. Y buscas y piensas, OK, ¿qué aplicación de terceros, tal vez CI/CD, necesitas usar? ¿Vamos a alojar esto en AWS? ¿Como hacemos eso? ¿Qué servicios? Y luego implementas este tipo de soluciones potencialmente ad hoc en torno a ese flujo.

Bueno, la plataforma Atlas y WordPress Engine Atlas realmente resuelve esto. Aquí es donde entra en juego. Elegimos ir con Atlas por todas esas razones, y tienen esta infraestructura de servicio administrado. Estandarizan la canalización de CI/CD. Realmente no tienes que pensar en ello.

Hay migraciones de datos entre los entornos que se reducen esencialmente a un flujo de un solo clic. Históricamente, eso siempre ha sido un gran problema al pasar del control de calidad a la puesta en escena y a la producción. Esencialmente, WordPress Engine y la plataforma Atlas lo han reducido a un solo clic.

Y luego está la fatiga en torno a los microservicios y DevOps. Solo hay una gran carga cognitiva de cuánto tiene que pensar y apoyar y ser consciente de eso como desarrollador y mantenerlo en funcionamiento. Estas son todas las cosas que la plataforma Atlas realmente te quita de las manos y las resuelve de manera beneficiosa.

Así que hablemos de algunas de las dinámicas que creo que headless realmente promueve y enfatiza. El primer pilar aquí, hay tres de ellos. El primer pilar es la experiencia del desarrollador. Nos permite elegir la herramienta adecuada para el trabajo. Y cuando digo nosotros, me refiero a los desarrolladores.

Nos permite elegir una pila en la que queremos escribir código. Y eso es, para nosotros, eso es en Haus, eso es Next.js y React. Next.js es simplemente un marco maravilloso en torno a algunas convenciones realmente agradables para el enrutamiento y el rendimiento y la arquitectura de la aplicación. Y también queríamos implementar un sistema de diseño, y no solo un sistema de diseño visual sino un sistema de diseño codificado. Esto es algo que mantiene nuestra aplicación consistente, probada y hermosa.

Las interacciones son consistentes. Nos permite crear nuevas páginas y funciones en ese ecosistema en el futuro, y mantener eso y mantener esa consistencia. También nos permite escribir código expresivo declarativo y React lo respalda como biblioteca. Pero también creemos en ese estilo de escribir en equipo. Nos permite elegir esa pila para nosotros en el front-end, mientras que tal vez un sitio tradicional de WordPress basado en temas, realmente no tenemos el mismo lujo.

También necesitamos mucho margen creativo. Puede ver cuando visita leoburnett.com, hay hermosas transiciones de página. Hay, no estamos atados a la pila tradicional de WordPress sobre cómo se deben representar las cosas. WordPress ya no está a cargo de renderizar la interfaz.

Nuestro margen de maniobra es virtualmente ilimitado. Podemos elegir nuestras bibliotecas de animación. Podemos elegir la forma en que nuestros componentes interactúan entre sí. Es un gran beneficio en el lado DX.

La experiencia de administración es elevada y creo que la hemos optimizado porque nunca nos alejamos de su antigua familiaridad. No hay corte de back-end. Pasamos de WordPress a WordPress. No tuvimos que exportar datos y escribir scripts para pasar a otro sistema propietario. Así que la familiaridad es enorme. Queríamos mantener ese tipo de flujo para los administradores actuales de leoburnett.com.

Adopción y documentación: si pasa cinco minutos en la web, probablemente haya tocado un back-end de WordPress, y eso simplemente no se puede exagerar. Leo Burnett también tiene muchos puntos de contenido muy específicos y campos personalizados. WordPress ofrece eso y te da ese poder, pero pudimos implementar el complemento Advanced Custom Fields, que es una muy buena convención para ajustar la interfaz de usuario del administrador para que sea realmente amigable y utilizable. Así que fue una victoria en la experiencia de administración.

Ahora, por supuesto, el tercer pilar es la experiencia del usuario. Es lo que realmente importa. Usuarios, creo que al igual que creemos que las aplicaciones web en Haus deberían sentirse como aplicaciones nativas, no debería haber abandono. Creo que los usuarios realmente aprecian eso también.

Son sin costura. Son receptivos. Simplemente se sienten bien. Y creo que queríamos que Leo Burnett y todas nuestras aplicaciones se sintieran de esa manera. Poder elegir la pila que queremos en el front-end nos permite hacer eso.

Las aplicaciones nativas están intrínsecamente desvinculadas de sus infraestructuras de contenido back-end, al igual que nuestras aplicaciones web. Y esto es lo que promueve Atlas. Esto es lo que promueve la arquitectura sin cabeza en general. También promueve el rendimiento. Podemos renderizar universalmente nuestra interfaz de usuario. Eso significa que la carga inicial está en el lado del servidor. Y después de eso, el cliente se hace cargo.

Hay muchos beneficios aquí. Una es que hace felices a los motores de búsqueda. Son contenido del lado del servidor. Es rápido. También nos permite pre-renderizar virtualmente instantáneamente la siguiente página y hacer esas solicitudes basadas en lo que hay en la ventana gráfica una sola vez.

Para Leo Burnett, en términos de la API de contenido que elegimos consumir, configuramos un punto final de GraphQL. Eso significa que están regresando cargas útiles más ligeras. Estamos definiendo explícitamente exactamente el contenido que necesitamos. Hay menos hidratación después de que el lado del servidor se renderiza en el lado del cliente.

Eso es menos código llegando por cable, menos respuesta, tiempos de respuesta más rápidos. Definitivamente es una victoria, y sugeriría que si va a pasar a un flujo de trabajo Atlas o un flujo de trabajo sin cabeza, analice detenidamente el uso de la API GraphQL en lugar de quizás algo como una API REST.

Y desde la perspectiva del usuario, ven contenido nuevo y oportuno. Este es un flujo de publicación que está optimizado para obtener una vista previa del contenido. Está optimizado para obtener contenido rápido en el lado de la puesta en escena y las vistas previas y luego promoverlo en producción. Los administradores de Leo Burnett están muy contentos con lo fácil que es actualizar el contenido, y eso hace felices a los usuarios.

¿Cuál es el resultado? Esto es solo para enrollarlo todo. Es desarrolladores inspirados, administradores productivos y usuarios satisfechos. Esta es la tríada y la esperanza por la que creo que todos los equipos de desarrollo web realmente se esfuerzan.

Cuando los desarrolladores están inspirados, utilizan un conjunto optimizado de herramientas. Simplemente se siente bien. Están contentos. Escriben mejor código.

Los administradores saben que están produciendo contenido en un hermoso ecosistema. Es rápido. Se envía rápidamente. Y los usuarios están viendo ese contenido actualizado, y están experimentando una interfaz moderna, hermosa, que funciona bien y optimizada.

Creo que para terminar, solo algunos pensamientos finales que me encantaría que tuvieras en cuenta. Pienso que al brief, per se, siempre le falta lenguaje. Creo que con demasiada frecuencia solo hablamos de, oye, crea un sitio web hermoso. Constrúyeme un sitio web increíble. Quiero que se vea y se sienta, y hemos realizado todas estas revisiones con los clientes.

Y todo el mundo se emociona, y luego llega V1, y se lanza. Y luego las personas que necesitan hacerse cargo de ese sitio web son como, me diste un lío. ¿Cómo me ocupo de esto? ¿Es este un flujo ad hoc que concibió?

No desea crear un sitio web hermoso y entregar una carga. Estamos muy orgullosos aquí en Haus de no hacer eso. Y creo que lo maravilloso de Atlas y Atlas como plataforma es que resuelve eso.

Le da la confianza de que está enviando un ecosistema y un sistema de publicación web que realmente tiene sentido desde el punto de vista de la infraestructura y el punto de vista de la implementación del código. Le da una prueba documentada al equipo de TI y al equipo de ingeniería o al equipo de marketing de que sabe lo que está haciendo y que ahora están en buenas manos con este nuevo sitio web que creó para ellos.

Porque recuerda, no solo estamos construyendo un sitio web. Estamos estableciendo un sistema de publicación de contenido, y es fundamental comprenderlo y reconocerlo desde el primer día. Y nuevamente, aquí es donde Atlas entra en juego.

Así que espero que ese pequeño dato te ayude a concebir estratégicamente tu stack sin cabeza en el futuro. Si esa es la dirección que desea tomar, le recomiendo que eche un vistazo a Atlas. Espero que os haya gustado la sesión, y muchas gracias.