Usando GraphQL en WordPress

Hola, soy Sid y hoy voy a hablar sobre la construcción de sitios web modernos con WordPress y GraphQL. Así que un poco sobre mí, vivo en Mumbai, India. Trabajo en Gatsby Inc, ayudo a mantener el código abierto de Gatsby, también ayudé a construir compilaciones incrementales en Gatsby Cloud. Actualmente, estoy trabajando en Gatsby Functions, que es una implementación sin servidor integrada en Gatsby, pronto estará disponible. También estoy escribiendo un libro llamado Desarrollo web para todos. Puedes consultarlo en webdevelopmentforeveryone.com.

Además de eso, más cosas sobre mí, pero ahora cosas divertidas, me gusta bucear, especialmente en naufragios y peces jacks. También estoy aprendiendo a volar un avión este año los fines de semana. Y también estoy tratando de comprar una PS5, si sabes dónde está disponible, por favor avísame.

Así que ahora hablemos sobre el Jamstack porque eso es de lo que me pagan para hablar. Si te gusta el Jamstack como a mí, probablemente estés construyendo sitios usando Gatsby, Next, Hugo o Eleventy. Y cuando construyes estos sitios estáticos, es probable que obtengas datos de múltiples fuentes de datos diferentes. Una de ellas podría ser un CMS. Ahora hay muchos CMS geniales para elegir. Estos incluyen Contentful, Sanity, Tattoo CMS. Pero resulta que WordPress sigue siendo muy popular. WordPress todavía impulsa aproximadamente el 30% de todos los sitios web en la web en 2020. Y WordPress es un gran CMS. Quiero decir, ya sabes, tiene una experiencia de escritura familiar. Las personas lo han estado usando durante años, por lo que están realmente cómodas con cómo funciona. Tiene una gran cantidad de complementos para hacer realmente cualquier cosa que desees hacer con él, incluyendo cosas como campos personalizados avanzados, WooCommerce, comercio electrónico gratuito, y más. WordPress también es de código abierto, y eso es genial porque significa que no hay límite, quiero decir, puedes construirlo en cualquier lugar y ejecutarlo en cualquier lugar. No estás limitado a una plataforma específica. Y típicamente, con muchos CMS, vemos que los usuarios, ya sabes, el número de usuarios que puedes tener en un espacio está típicamente limitado, y eso termina siendo un cuello de botella, especialmente cuando se trata de precios. Con WordPress, esto no es el caso. Así que WordPress sigue siendo muy flexible y es un gran CMS para usar. Pero si estás construyendo un sitio en la actualidad, probablemente estés usando un marco de JavaScript, podrías estar usando React, Vue, Svelte, realmente cualquier cosa que te guste, pero cuando construyes tu sitio usando uno de estos marcos, típicamente vas a consumir tu instancia de CMS de WordPress utilizando su API REST. Y en el momento en que la API REST entra en escena, volvemos a ver esos problemas familiares, ¿verdad? Cosas como el exceso de recuperación, cosas como la falta de recuperación. Y resulta que renderizar una publicación simple se convierte en una cuestión de más de una, dos o incluso cinco solicitudes de red. Veamos un ejemplo concreto de cómo se ve esto.

Este es un sitio que construí. Esto es una maqueta. Y se llama The Good News Times porque todos podríamos usar algo de eso. Y esto se asemeja a muchos sitios de noticias populares. Y como puedes ver, hay un montón de tarjetas. Cada tarjeta es un artículo. Tiene una imagen, un título, algo de texto. También tiene un autor y una imagen de autor. Correcto. Y tenemos cuatro artículos en esta página de inicio.

Ahora, para renderizar esta página, que nuevamente, como dije, tiene publicaciones y autores, necesitas hacer nueve llamadas de API a WordPress si usas la API REST. Y he enumerado todas estas llamadas de API y verás que hay una para obtener todas las publicaciones en sí, y luego hay una para cada autor y una para cada imagen destacada. Eso suma nueve llamadas de API para solo cuatro publicaciones. Y eso es mucho. Correcto. Ahora, ya sabes, en el pasado, hemos usado GraphQL para envolver API REST. Y cuando haces eso, en el cliente, eso ayuda a simplificar tu base de código. Pero aún así es lento porque sigues haciendo nueve llamadas de API. Y es mucha data a través de la red. Correcto. Y también es frágil porque si tienes código que tal vez una de esas llamadas de API falla, aún tendrás que manejar eso para cada una de ellas y asegurarte de manejar elegantemente todos esos casos de error. Además, no hace falta decir que esto no escala muy bien. Estamos viendo muchas solicitudes de API para una sola carga de página. Y en el momento en que hablamos de escala, esto se acumula.

Entonces intentemos pasar esto a GraphQL. De eso se trata esta charla. Se trata de construir sitios web modernos en WordPress con GraphQL. La forma en que vamos a hacer esto es utilizando WPGraphQL. Si no has visto WPGraphQL antes, es un complemento para WordPress. Te brinda una API GraphQL con un solo clic desde el principio.

Simplemente instálalo. No necesita ninguna configuración para comenzar y obtienes una API de GraphQL. También tiene complementos para cosas realmente populares en WordPress como WooCommerce y campos personalizados advanced.

Ya he configurado un sitio de WordPress aquí, como puedes ver, se está ejecutando localmente en mi máquina. Se llama Good News Site. También he instalado el complemento. Como puedes ver en nuestra página de complementos, ahí lo tienes, ves que ya tenemos WPGraphQL instalado.

Echemos un vistazo a lo que nos ofrece. Lo primero que vemos es este botón de entorno de desarrollo integrado gráfico realmente agradable. Vamos a hacer clic en eso. Ahí lo tienes. Vemos nuestro entorno de desarrollo integrado gráfico familiar. Esto es genial. Esto nos ayudará a escribir nuestra consulta.

Volviendo a nuestro código, veamos qué necesitamos hacer para migrarlo a GraphQL. Tenemos este proyecto de muestra aquí. Lo que hace este proyecto es, como vimos antes, mostrar un montón de tarjetas. Cada una de estas tarjetas se muestra a partir de algunos artículos. Esos artículos se obtienen en este gancho personalizado de React, que realiza un montón de esas llamadas a la API, como puedes ver. Luego los transforma en una forma que requiere nuestro componente de Tarjeta. Luego, nuestro componente de Tarjeta los muestra. Por ahora, esto funciona bien. Se está ejecutando en localhost 8000. Puedes ver que realiza esas solicitudes y muestra estas tarjetas.

Continuemos. Antes de continuar, aún podemos ver que hay un montón de esas llamadas a la API. Ves 1, 2, 3, 4, 5, 6, 7, 8. Deberían ser 9, pero veo 8 ahora mismo. Tal vez estoy contando mal. Ahí lo tienes.

Ahí está el noveno. Estas son todas las llamadas a la API que se están realizando. Eso es mucho. Ya hemos hablado de eso. Vamos a hacer que esto funcione con GraphQL.

Lo primero que voy a hacer es echar un vistazo a todos los data que necesitamos. Necesitamos un título, descripción, slug, URL de la imagen, nombre del autor y URL del avatar. Vamos a escribir nuestra consulta de GraphQL. Para hacer eso, verás que no lo leeré ahora porque practiqué esto hace un tiempo. Voy a borrar eso. Vamos a escribir esta consulta de GraphQL desde cero.

Lo primero que vamos a necesitar son las publicaciones. Queremos todas ellas. Por ahora solo tenemos cuatro publicaciones. De lo contrario, podríamos agregar un filtro, pero lo ignoraremos por ahora. Para cada publicación, queremos el título, el contenido, el autor. Resulta que tiene una nota que tendrá el nombre del autor. También queremos su avatar, que creo que también tiene un nodo. Oh, no lo tiene. Solo tiene una URL. Eso es genial. Ahora tenemos toda la información sobre la publicación y el autor, pero también necesitamos la imagen destacada. Creo que se llama... Ahí está. Se llama imagen destacada. Qué conveniente. Eso tiene un nodo con una URI, también tiene una URL de origen, así que vamos a usar eso. También probablemente necesitemos el slug, porque eso nos ayudará a tener alguna especie de clave para cada publicación. Así que vamos a obtener ese slug también. Voy a ejecutar esta consulta y, como puedes ver, obtengo todos los data, y eso es genial.

Simplemente funciona. Así que mantengamos esta consulta aquí. Volvamos atrás, configuremos GraphQL para nuestro proyecto. Creo que lo que queremos hacer en este caso es deshacernos de todo esto. Me encanta eliminar código, ¿verdad? Así que eliminemos todo eso. Y ahora que eso se ha ido, importemos, importemos use query de urql. Me encanta urql. Creo que Patty está hablando de urql hoy, o tal vez ayer, pero de todos modos, escribamos una consulta.

Lo que vamos a hacer es obtener un resultado de useQuery y luego llamar a eso. Creo que esto toma, ahí tienes, toma un objeto que tiene una consulta, y eso puede ser una cadena, y voy a copiar esto, pegarlo aquí. Y antes de que esto funcione, vamos a querer envolver nuestros componentes de diseño. Hagámoslo. Importemos, creo que se llama createClient y Provider de urql y creemos un cliente. Creo que eso necesita una URL, ahí tienes, y nuestra URL en este caso va a ser nuestro sitio slash GraphQL, como estamos acostumbrados a ver. Así que vamos a configurar eso. Y también vamos a establecer preferir el método get en true. Creo que Oakley usa post por defecto WP GraphQL prefiere get, así que vamos a, vamos a quedarnos con get por ahora. Así que tenemos un cliente, vamos a envolver, acabo de darme cuenta de que esto probablemente debería haber sido index, así que vamos a mover esto a nuestro index y luego envolver el diseño en lugar de ponerlo en el diseño, ¿verdad? Así que voy a, ahí tienes. Eso debería estar bien. Y ahora envolvamos nuestro proveedor aquí. Vamos a establecer un valor para el cliente. Y creo que eso es todo lo que necesitamos. Así que tenemos nuestro proveedor en su lugar, tenemos nuestro componente de artículo que, ya sabes, llama a esta consulta. Vamos a desestructurar nuestros data y obtener de nuestro resultado en orcl. Y finalmente, ¿por qué se queja esto? Porque todavía estoy dentro de la función. Ahí tienes. Así que pongámoslo ahí. Registremos data. También vamos a decir que si fetching es verdadero, probablemente queramos devolver nulo, ¿verdad? Echemos un vistazo a nuestros registros y veamos si eso funciona y qué hace. Así que vemos...

Interesante. ¿No se guardó eso? Hmm. Correcto. Hay un error y se niega a compilar porque articles ya no existe... Ahí lo tienes. Articles no existe. Voy a comentar esto y actualizar. Y vemos que ahora tenemos data además de todos los demás errores. Tenemos data con publicaciones y notas.

Así que tenemos nuestros data. Ahora vamos a escribir todo lo que necesitamos para que se renderice. Así que voy a... Creo que necesitamos transformar un poco nuestros data porque el formato de data que tenemos de WP GraphQL va a ser ligeramente diferente al que teníamos de la API REST. Así que vamos a mapear estos, y digamos que cada uno de ellos es una publicación, y vamos a devolver un objeto determinado, ¿verdad? Y sabemos que queremos cosas para nuestras tarjetas. Copiemos esas claves aquí. Digamos que esto es nombre, y esto es URL del avatar. Deberíamos poder establecer estos bastante rápido. El título es post.title, como sabemos, porque escribimos la consulta. La descripción va a ser post.content. El slug puede ser simplemente post.slug. La URL de la imagen, supongo, es post.featuredImage.node.sourceUrl. Finalmente, el autor va a ser post.author.node.name. Y la URL del avatar va a ser post, bueno, no puedo escribir hoy. De todos modos, esto va a ser post.author.node.avatar.url, ¿verdad? Creo que esto debería funcionar, así que vamos a...

Muy bien, no hay errores. Echemos un vistazo a nuestro cliente. Actualicemos y ahí lo tienes, funciona perfectamente. Tenemos toda la página renderizada, todas nuestras tarjetas se ven bien, tiene todos los data que buscábamos. Así que simplemente tomamos JavaScript, como un sitio construido con React, o realmente cualquier, podrías usar cualquier marco de JavaScript, pero simplemente tomamos un poco de código JavaScript que llamaba a un montón de estas API REST y lo cambiamos para usar GraphQL con WP GraphQL en cuestión de minutos. Y fue así de fácil.

Entonces sí, hablemos de algunas comparaciones rápidas. Nuestra API REST necesitaba alrededor de nueve solicitudes para renderizar esa página. WP GraphQL, con GraphQL, solo necesitábamos hacer una solicitud de red en total. La API JSON eventualmente tomó aproximadamente un segundo y un poco más de un segundo, WP GraphQL tomó menos de un tercio de eso. Y eso es genial porque si miras la cantidad de datos también, y todo esto se ejecutaba localmente, pero por supuesto, estos números pueden crecer dramáticamente cuando ejecutas esto, como cuando estas cosas suceden a través de la red. Para la API JSON, descargó 13.7 KB, mientras que para nuestra solicitud de GraphQL, descargó 1.6 KB.

Realicé algunas pruebas de carga, pude golpear la API REST con aproximadamente cientos de solicitudes por segundo, mientras que la API GraphQL pude golpear alrededor de mil por segundo. Eso es aproximadamente una diferencia de 10X. Bueno, no aproximadamente, esa es una diferencia de 10X.

Entonces sí, eso es lo que es WP GraphQL. Es una excelente manera de hacer que GraphQL funcione en tu proyecto de WordPress. WP GraphQL es un proyecto patrocinado por Gatsby. Funciona de manera predeterminada con Apollo o KIL. Realmente cualquier pila que desees. Tiene complementos para todas las funciones comunes de WordPress. También se utiliza en producción por qz.com y apollographql.com y Denver Post y muchos más. Ha estado presente durante un tiempo, se ha utilizado en producción en casos importantes. También alcanzó recientemente la versión 1.0 y eso es importante porque marca su primer lanzamiento estable. Mis diapositivas tienen un enlace a las notas de lanzamiento para la versión 1.0, así como al artículo del blog que escribió Jason. Y con eso, eso es WP GraphQL. Funciona de manera predeterminada, como dije, con cosas que usan GraphQL en tiempo de ejecución. De manera predeterminada con cosas que usan GraphQL en tiempo de ejecución. Como Apollo u Opel o si deseas usar GraphQL en tiempo de compilación como lo hace Gatsby, eso también funciona de manera predeterminada con WP GraphQL. Y realmente, como dije antes, debería funcionar con cualquier pila. Es solo una API. Esto realmente convierte a WordPress en un CMS sin cabeza. Y eso es todo en mi charla. Me gustaría agradecer a Jason. Quien construyó WP GraphQL a lo largo de los años, y esta es una foto divertida de él posando como el Rey Tigre. También está su Twitter en esta diapositiva.

Adelante y síguelo. Es fantástico. Tyler, quien también es otro compañero mío, ha estado construyendo Gatsby source WordPress. Así que si te gusta Gatsby y quieres usar WP GraphQL con un sitio de Gatsby, entonces este es el indicado para construir.

Gatsby source WordPress, su nueva versión que Tyler ha estado construyendo, funciona de inmediato. Es mucho más rápido que las versiones anteriores que utilizan la API REST. Puedes seguirlo en Twitter. También resulta ser el chico canadiense más amable, ya sabes. Y eso es mucho. Eso dice mucho porque los canadienses son amables.

Y sí, espero que WP GraphQL te haga tan feliz como Peppa Pig hace feliz a mi sobrina. Gracias. Hola, ¿cómo estás? Hola, estoy bien. Gracias por la amable introducción. Esto fue divertido. Absolutamente. No voy a decirle a la gente que me pediste secretamente que te presentara de una manera muy, creo, seria. Sí. Sí. No se lo digas a nadie. Sí. No lo menciones. Absolutamente. Sí. El secreto es entre nosotros.

Increíble. ¿Revisaste los resultados de tu encuesta o fueron... Fueron interesantes? ¿Qué esperabas? Sí, también fueron sorprendentes porque, bueno, de cierta manera, supongo que fueron sorprendentes y también un poco no sorprendentes porque es una idea errónea común que la gente tiene con el hecho de que piensan que construir sitios realmente grandes con generadores de sitios estáticos como Gatsby es problemático. Hemos invertido mucho tiempo y seguimos haciéndolo para que Gatsby funcione mejor a gran escala. Y de hecho, tenemos muchos clientes en Gatsby Cloud que actualmente están construyendo sitios que están en los miles.

Entonces, si estás construyendo un sitio que tiene aproximadamente, ya sabes, mil o incluso 10,000 páginas, está bien. Debes esperar que se construya en 30 a 45 minutos incluso. Sí, puedes construir sitios mucho más grandes que 100 páginas con cosas como Gatsby.

Eso es increíble. Es muy interesante descubrirlo.

Antes de comenzar con tus preguntas y respuestas, tengo una pregunta muy interesante para ti. También mencionaste, en realidad mencioné en tu introducción, que te encanta bucear como deporte. Entonces, ¿cuál fue tu mejor momento buceando? ¿Encontraste algo interesante bajo el agua?

Esa es una gran pregunta. No me lo esperaba. Gracias por preguntar eso. Me encanta bucear, sí, y ha habido muchas inmersiones que consideraría entre mis favoritas. Creo que una de mis inmersiones favoritas fue en las Maldivas el año pasado. Fue una inmersión nocturna, así que fue después de las 7 p.m. Estaba muy oscuro. Lo único que podíamos ver eran las linternas bajo el agua. Y recuerdo haber visto una pequeña tortuga que estaba dormida, ya sabes, debajo de un coral. Y me emocioné mucho porque quería contarle a todos sobre la tortuga, porque se veía tan hermosa, que empecé a iluminarla con mi linterna y la desperté. Se levantó, me miró y luego nadó lejos. Así que fue triste. Me siento terrible por eso. Pero fue hermoso. Amo las tortugas. Es como la historia de la tortuga dormida, excepto que despertaste a la tortuga y eres el príncipe cruel en lugar del príncipe encantador. Sí. Lo siento.

Muy bien. Sin más preámbulos, pasemos directamente a tus preguntas y respuestas. Tenemos una pregunta de nuestros asistentes en Discord. La pregunta es, ¿puedes explicar el concepto de las suscripciones de data?

Claro. Absolutamente.

Las suscripciones de datos no están disponibles en este momento. Quiero decir, si estás hablando del concepto, el concepto es bastante simple. Por lo general, a través de GraphQL, puedes enviar solicitudes para obtener algunos datos. Y solo recibirás una respuesta, lo cual también puedes hacer en, ya sabes, en algunos frameworks en este momento, en los que puedes, en lugar de hacer una solicitud, abrir una conexión de socket y recibir respuestas a medida que se actualizan. Y eso funciona muy bien para aplicaciones en tiempo real. En el contexto de mi charla, WPGraphQL actualmente no admite suscripciones de datos. Entonces, quiero decir, la única forma de obtener datos nuevamente es mediante la consulta periódica de cosas. Pero es interesante porque he escuchado a Jason mencionar que es algo en lo que les gustaría trabajar. Y sí, ve al problema. Habla con Jason y las demás personas de WPGraphQL en GitHub y diles que te gustaría ver las suscripciones más pronto. Eso es genial. También es una gran oportunidad aquí para las contribuciones de la comunidad, veo. Absolutamente. Quiero decir, si puedes escribir PHP mejor que yo, no puedo escribir mucho PHP. Siéntete libre de echar un vistazo a WPGraphQL y contribuir. Nos encantaría eso. Genial.

Entonces, otra pregunta para ti es ¿cuáles son los beneficios de usar el nuevo complemento de WordPress obtenido de Gatsby en comparación con Gatsby obtenido de GraphQL? Esa es una excelente pregunta. Si estás utilizando, si resulta que estás utilizando Gatsby y estás usando WPGraphQL en WordPress para obtener datos, hasta hace muy poco, la única forma de consumir esos datos era utilizando Gatsby obtenido de GraphQL. Y Gatsby obtenido de GraphQL, en caso de que no estés familiarizado, es un complemento de Gatsby para obtener datos de cualquier punto final de GraphQL arbitrario. Y funciona muy bien, pero hay ciertas optimizaciones que hemos realizado en el nuevo complemento experimental de WordPress obtenido de Gatsby, que permite cosas como vista previa en tiempo real y compilaciones incrementales en Gatsby Cloud, todas las cuales no son compatibles con Gatsby obtenido de GraphQL. Entonces sí, el mayor beneficio de usar WordPress obtenido de Gatsby, la nueva versión, con WPGraphQL es que obtienes vista previa en vivo de forma predeterminada y también obtienes compilaciones incrementales. Entonces, en caso de que hayas utilizado Gatsby obtenido de GraphQL en el pasado, intenta trasladar tu sitio a WordPress obtenido de Gatsby, y si eso es difícil o si encuentras problemas, no dudes en abrir un problema en GitHub y estaré encantado de ayudar. Pero sí, ese es el beneficio principal, eso es lo que recomendaría. Eso es genial, es una excelente respuesta. En realidad, no sabía esto, así que esto es como un momento de `Hoy Aprendí` para mí, definitivamente lo revisaré yo mismo. Además, voy a intentar ver si podemos hacer otra pregunta antes del descanso. Genial. ¿Cómo WPGraphQL admite ACS y otros complementos populares de WordPress? ¿Qué opinas al respecto? Esa es una excelente pregunta. WordPress es una plataforma agradable porque tiene una gran cantidad de complementos, muy buenos complementos. Como mencioné en mi charla, esa es una de las razones por las que es tan popular. WPGraphQL admite ACS, que es un complemento de WordPress muy popular. Se llama Advanced Custom Fields. También está WooCommerce y Custom Post Types, entre otros. WPGraphQL tiene sus propios complementos que también puedes instalar para agregar soporte para estos otros complementos. Voy a enlazar la página de complementos de WPGraphQL en Discord. Así que echa un vistazo a eso. Pero sí, la respuesta corta es que admite la mayoría de estos complementos realmente populares de WordPress. Y al instalar estos complementos, las cosas deberían funcionar de inmediato. Deberías poder consultar tu punto final de GraphQL ahora enriquecido con datos de estos otros complementos sin ningún otro trabajo. De acuerdo, genial. Esa fue una excelente respuesta. Muchas gracias. Y también para ustedes, estén atentos al enlace que mencionó Sid en Discord. Muchas gracias, Sid. Esa fue una charla increíble y una sesión de preguntas y respuestas aún más interesante e informativa contigo. Muchas gracias por tu tiempo. Gracias. Adiós.