Video Summary and Transcription
WordPress es ampliamente utilizado y ahora admite una API REST para uso sin cabeza. Servir archivos HTML estáticos permite escalar infinitamente y sobrevivir al tráfico viral. GraphQL se puede utilizar para interactuar con los datos de WordPress, reduciendo la complejidad. WordPress se puede acoplar con complementos como Yoast y ACF, y WPGraphQL funciona perfectamente con estos complementos. GraphQL permite seleccionar solo los datos necesarios y tiene ventajas de rendimiento sobre las API REST.
1. Introducción a WordPress y CMS sin cabeza
WordPress todavía se utiliza ampliamente, con un 37% de los sitios principales de un millón que lo utilizan. Ahora admite una API REST, lo que permite su uso sin cabeza. Los generadores de sitios estáticos y los marcos web modernos pueden hacer el trabajo pesado antes de que se cargue la página, evitando la necesidad de solicitudes del lado del cliente a WordPress.
B-R-E-A-C-K-E-R-Y-S-T-Y-F-R-O-K-K-Y-S-T-Y-F-R-O-K-K-Y-S-T-Y-F-R-O-K-K-Y-S-T-Y-F-R-O-K-K-Y-S-T-Y-F-R-O-K-K-Y-S-T-Y-F-R-O-K-K-Y-S-T-Y-F-R-O-K-K-Y-S-T-Y-F-R-O-K-K-Y-S-T-Y-F-R-O-K-K-Y-S-T-Y-F-R-O-K-K-Y-S-T-Y-F-R-O-K-K-Y-S-T-Y-F
Puedes encontrarme prácticamente en cualquier lugar de la web simplemente buscando mi nombre, ya que soy el único en el mundo. Así que empecemos abordando el CMS en la sala. Es 2021 y algunos desarrolladores aún se estremecerían ante la idea de usar WordPress. Pero francamente, todavía vivimos en un mundo de WordPress. Según Build With Trends hace un tiempo, si observamos la distribución de CMS de los principales sitios de un millón, el 37% de los sitios web están utilizando WordPress. Eso es un porcentaje enorme. Y estoy seguro de que ha aumentado hasta ahora, y no estoy seguro de qué tan preciso es, pero si observas el número de detecciones en el sitio de Build With, hay más de 960 millones de instalaciones de WordPress. Eso es casi mil millones. Es un número impresionante.
Si bien es posible que no todos queramos usar WordPress, es realista que se quede por un futuro previsible. Pero espera, ¿por qué estoy hablando de WordPress? Bueno, retrocediendo un poco, WordPress, como tradicionalmente lo conocemos, es un CMS y una solución de sitio web todo en uno. Funciona para obtener todos los datos de la base de datos, renderizarlos a HTML y luego enviarlos a el navegador. Pero desde la versión 4.7, WordPress ahora admite una API REST. Esto significa que de entrada realmente podemos usar WordPress sin cabeza. Si no has oído hablar del término sin cabeza antes, ¿qué significa realmente? Bueno, con nuestra pila tradicional como WordPress, alguien visitará una página en el navegador. El navegador se conecta al servidor, el servidor hará el trabajo como hacer esas solicitudes a la base de datos, renderizar el HTML de la página y luego enviar esa respuesta. Si tenemos suerte, la devolverá en caché. Finalmente, el navegador mostrará esa respuesta a la persona que visita ese sitio. Con un enfoque sin cabeza, esa solicitud al servidor podría ser asíncrona en el cliente. En este ejemplo en particular, la persona visitaría una página en su navegador y obtendría inmediatamente una respuesta directamente desde el almacenamiento. Una vez que esa página se carga en el navegador, el navegador iniciará otra solicitud a un servidor que puede cargar todo ese contenido dinámico. Pero me imagino que probablemente te preguntes por qué querríamos hacer una solicitud del lado del cliente a WordPress para un CMS. Esa no es necesariamente la forma recomendada. Ahí es donde entran en juego los generadores de sitios estáticos y los frameworks web modernos. Hacen todo el trabajo duro antes de que la página llegue al navegador. Podemos usar frameworks front-end para obtener todos esos datos en tiempo de compilación o con representación en el lado del servidor, evitando ese costo dentro del navegador. Ahora, si todo esto te suena nuevo, puede parecer mucho trabajo. ¿Por qué incluso, por qué molestarse con una API? ¿Por qué no usar WordPress tal como lo hacemos siempre? Así que centrémonos en este ejemplo de usar una API con un sitio estático, donde la única vez que nos comunicamos con esa API es en tiempo de compilación. Y almacenamos los archivos HTML directamente en el almacenamiento. Obtenemos muchos beneficios al evitar hacer solicitudes directas al servidor en cada una de esas solicitudes. Con la mayoría de nuestras soluciones base, soluciones basadas en el servidor como WordPress,
2. WordPress y CMS sin cabeza
Los complementos de WordPress y el trabajo personalizado pueden ayudar con el almacenamiento en caché, pero cada página sigue siendo una carga para el servidor. Los archivos HTML estáticos, servidos desde el almacenamiento o un CDN, son más rápidos. El equilibrio de carga y la escalabilidad automática no son soluciones perfectas. Servir archivos HTML estáticos permite una escalabilidad infinita y sobrevivir al tráfico viral. El almacenamiento es barato y la gestión de servidores puede ser costosa. La API REST en WordPress permite obtener todos los datos, incluidas las publicaciones del blog y la información del autor.
hay muchas opciones para acelerar las cosas. Para WordPress en particular, eso incluye algunos complementos para almacenar en caché o algún trabajo personalizado en el fondo, pero cada página sigue siendo una carga para el servidor, lo cual está sujeto a sus altibajos. Por otro lado, con nuestro sitio estáticamente compilado, un archivo HTML estático será simplemente rápido. En lugar de pasar tiempo renderizando en un servidor, sirves un archivo estático directamente desde el almacenamiento o un CDN. Si bien puedes hacer esto de forma predeterminada con WordPress, a menudo es mucho más complicado. Y algunos de los complementos que almacenan en caché pueden servir un archivo HTML, pero aún lo sirven desde un servidor regular, no desde un almacenamiento estático. Con cualquier servidor, generalmente pagamos en función de cuánto esperamos que sea nuestro tráfico. Si bien la mayoría de las veces eso es predecible, todos esperamos tener algún día una publicación viral, y si eso sucede, las personas que visitan nuestro sitio serán las que lo paguen con velocidades lentas o tiempos de espera. Hay soluciones como el equilibrio de carga y la escalabilidad automática, pero no son soluciones perfectas y es posible que no siempre podamos manejar ese tráfico en particular. Volviendo al hecho de que estamos sirviendo archivos HTML estáticos, porque los estamos sirviendo directamente desde el almacenamiento, o mejor aún, estáticamente desde el CDN, alerta de palabra de moda, eso significa que nuestro sitio web orientado al usuario va a escalar infinitamente. Ese sitio estático sobrevivirá al abrazo de la muerte de Reddit cuando tu publicación se vuelva viral. Pero la gestión de servidores no siempre es barata. Si bien un blog personal con poco tráfico podría manejar unos pocos dólares al mes, cuanto más crece ese tráfico, más crecerá ese costo. Si bien todavía tienes opciones como el equilibrio de carga y la escalabilidad automática, los servicios se suman rápidamente. Sin ellos, nuevamente corres el riesgo de que tu sitio se ralentice o, peor aún, tenga tiempo de inactividad. Pero el almacenamiento es barato. Es realmente barato. Podemos mantener proyectos estáticos enormes en AWS utilizando S3 a un costo muy bajo. Pero incluso si todavía administramos un servidor, el uso será mucho, mucho menor porque solo tenemos que lidiar con los administradores de contenido o las solicitudes en tiempo de compilación. Ahora, espero haber te convencido de por qué sin cabeza es algo bueno. O al menos haber establecido algo de contexto sobre lo que viene a continuación. Entonces, ¿cómo aplico esto a WordPress? Bueno, volvamos a la API REST. Si quiero comenzar a construir mi nuevo blog estático, en última instancia, necesitaré obtener todos mis datos. Comenzaré yendo a WP.json, que contendrá información básica sobre mi sitio web, junto con una lista de rutas que muestran qué puntos finales están disponibles para acceder. A continuación, quiero agregar mis publicaciones de blog. Entonces, puedo acceder al punto final de publicaciones y obtenerlas fácilmente todas. Luego, simplemente las cargo dentro de mi aplicación y las itero a través de todas ellas en la interfaz de usuario. Pero quiero agregar más detalles a esto. Quiero saber, por ejemplo, quién es el autor. Entonces, encuentro el ID del autor en la publicación y probablemente no tenga sentido acceder a cada autor individualmente, porque eso podría ser muchos autores. Entonces, accedo a los autores
3. Using GraphQL to Interface with WordPress Data
Para evitar hacer múltiples solicitudes y lidiar con relaciones de datos complejas, podemos usar GraphQL para interactuar con nuestros datos de WordPress. Al instalar el complemento WP GraphQL, podemos consultar nuestros datos de WordPress con GraphQL, obteniendo solo los datos necesarios con relaciones intactas. Esto reduce la gestión de datos y la complejidad. Al realizar solicitudes en el navegador, el impacto acumulativo de los KB y los milisegundos se vuelve notable, especialmente en sitios grandes. Next.js y WPGraphQL se pueden usar juntos para construir un hermoso blog de WordPress, con el Explorador GraphiQL que proporciona una forma interactiva de explorar y consultar los datos.
, intento hacer coincidir los data. Pero ahora también quiero mostrar algunas categorías en esa página. Entonces, nuevamente, encuentro los IDs, pero esta vez para las categorías, y solicito todas las categorías. Y, nuevamente, hago coincidir los data. Mirando lo que acabo de hacer, sin embargo, acabo de hacer cuatro solicitudes separadas para obtener los data que necesito para la página. Afortunadamente, en mi ejemplo, estoy compilando estáticamente , por lo que eso podría no terminar costándole al usuario, pero ciertamente hará que el desarrollo sea un poco más lento. Además de eso, la complejidad adicional de gestionar todos esos data y filtrarlos para que no pase realmente todos esos data como matrices gigantes como props en la página real, junto con la tensión adicional en la instancia de WordPress para todas esas solicitudes. Ahora, esto no pretende avergonzar a la API de WordPress, ni pretende decir que REST es inherentemente malo, pero estamos lidiando con relaciones complejas en nuestros data. No queremos estar limitados por puntos finales individuales, dejándonos con largas cadenas de solicitudes y más data del que realmente necesitamos. Queremos poder brindar la mejor experiencia posible.
Ahora, esto es GraphQL Galaxy, así que creo que probablemente sepas a dónde quiero llegar aquí, pero podemos mejorar seriamente la forma en que interactuamos con nuestros data de WordPress utilizando GraphQL. Y para hacer eso, gracias a Jason Ball, quien creó el maravilloso WP GraphQL, junto con todos los demás contribuyentes trabajadores, podemos agregar el poder de GraphQL a WordPress. Podemos hacer esto simplemente instalándolo como un complemento directamente en nuestro panel de control, lo que nos brinda la capacidad de consultar nuestros data de WordPress con GraphQL. Entonces, antes, estaba hablando de cómo no me gustaba la idea de tener que hacer todas estas cuatro solicitudes encadenadas. Entonces, en su lugar, podemos cargar nuestro cliente GraphQL como Apollo, y podemos hacer una sola solicitud con nuestra consulta. En lugar de tener que administrar cuatro volcados completos de data, donde necesitamos hacer coincidir todo y tener una lógica complicada y evitar inflar la aplicación, puedo consultar solo los data que necesito, con todas mis relaciones ya intactas, lo que significa que hay menos data que tengo que gestionar y mucha menos complejidad. Ahora, nuevamente, voy a hacer esto durante el tiempo de compilación, pero podemos ver el impacto realista de cómo se verían esas solicitudes haciendo la solicitud dentro del navegador. Si bien esos KB y milisegundos pueden no parecer mucho, realmente se acumula y se vuelve más notable en la experiencia de renderizado. Sin mencionar que no tengo muchas publicaciones en los puntos finales a los que realmente estoy accediendo aquí, así que imagina un sitio enorme que tiene muchas publicaciones. Además, eso fue en mi conexión de Fast Files. Es un poco diferente cuando vemos cómo se ve eso al limitar con algo como una conexión Fast3G. El punto final de la publicación con mi pequeña cantidad de publicaciones aún tardó tres segundos, por lo que realmente comienza a marcar una gran diferencia. Ahora, en última instancia, queremos integrar esto en nuestra aplicación. Queremos construir ese hermoso blog de WordPress. Aquí es donde entra Next.js. Como mencioné anteriormente, WPGraphQL está a solo una instalación de complemento de WordPress de distancia. Una vez instalado, inmediatamente tienes acceso a todos tus data. Lo genial es que con GraphQL, el Explorador GraphiQL se instala por defecto con WPGraphQL, y te permite explorar interactivamente todos tus data. Puedes hacer clic y ver todo lo que realmente puedes consultar directamente dentro de ese panel de control, y mientras lo haces en la columna central, en realidad está construyendo la consulta exacta que tú necesitas para tu aplicación. Y he hecho exactamente eso al crear lo que llamo el Next.js WordPress Starter, que permite a cualquier persona crear fácilmente un sitio de WordPress con Next.js. Como normalmente esperarías de un blog de WordPress, la página de inicio está llena de las publicaciones más recientes.
4. Using getStaticProps and getStaticPaths
Aprovecho getStaticProps para solicitar todas las publicaciones en tiempo de compilación y construir la página con paginación. Al usar getStaticPaths, definimos las rutas para nuestras publicaciones y volvemos a obtener los datos utilizando getStaticProps. Para evitar hacer solicitudes al servidor para la funcionalidad de búsqueda, creé un compilador de Webpack que obtiene las publicaciones en tiempo de compilación y crea un índice de búsqueda estático con títulos y rutas.
Aprovecho getStaticProps, donde solicito todas esas publicaciones en tiempo de compilación. Eso se inyecta en la página y puedo construir mi página exactamente como quiero con toda la paginación. Ahora, por supuesto, quiero asegurarme de que tengamos todas las rutas para nuestras publicaciones, para poder aprovechar getStaticPaths, que es cómo podemos decirle a Next.js exactamente qué rutas o páginas queremos asegurarnos de que se construyan. Y una vez que definimos esas rutas, podemos buscar los data nuevamente utilizando getStaticProps con cada uno de esos parámetros.
Imagino que alguien normalmente esperaría también una función de búsqueda, y la API de WordPress proporciona capacidades de búsqueda, pero como mencioné anteriormente, estoy tratando de compilar esto estáticamente, por lo que seguiríamos haciendo solicitudes al servidor, lo cual no quiero hacer aquí. Así que aproveché Next.js que se encuentra sobre Webpack, y creé un compilador de Webpack que obtiene todas las publicaciones en tiempo de compilación. Luego crea un índice de búsqueda, uno estático, con títulos y rutas dentro de ese archivo estático. Luego lo carga en memoria, o lo carga de forma asíncrona en el cliente, y podemos asegurarnos de que nuestra búsqueda esté correcta en ese índice.
5. Coupling WordPress with Plugins and WPGraphQL
Podemos acoplar WordPress con plugins familiares como Yoast y ACF, brindando flexibilidad en la gestión de contenido y datos. WPGraphQL funciona perfectamente con estos plugins, permitiendo consultar relaciones de datos con un solo punto final.
Lo bueno es que podemos acoplar esto con todos nuestros plugins de WordPress a los que estamos acostumbrados, como Yoast y ACF, donde esto nos brinda mucha flexibilidad en cómo gestionamos nuestro contenido y datos. Y todos estos funcionan perfectamente con WPGraphQL. Por lo tanto, aún estás consultando todas esas relaciones de datos con ese único punto final, con todo en su lugar.
Sé que no solo quieren ver capturas de pantalla de código, así que hagamos un recorrido rápido. Esto es lo que vamos a hacer. Primero, vamos a ingresar a una instancia existente de WordPress. Les mostraré cómo podemos instalar WPGraphQL fácilmente. Luego abriremos el Explorador de GraphQL para explorar y consultar un poco nuestros datos. Y finalmente, vamos a crear una nueva aplicación utilizando un ejemplo de inicio que creé, donde podremos ver algunas solicitudes existentes y tal vez ajustar esas solicitudes para ver cómo podemos obtener nuevos datos. Así que vamos a sumergirnos.
6. Querying Data with WPGraphQL
Vamos a instalar el plugin WPGraphQL para consultar datos de publicaciones con GraphQL. Después de instalar y activar el plugin, podemos usar la página Graphical IDE para explorar y construir consultas en tiempo real. Al abrir la publicación en el editor de consultas, podemos ver y agregar atributos como la fecha, ID y título. Con WPGraphQL, podemos consultar y recuperar datos para cada publicación. Utilizaremos un ejemplo de inicio más simple para demostrar cómo consultar datos en tiempo real y modificar la consulta. Para comenzar, copiaremos el comando de creación de yarn y usaremos create next app para clonar el proyecto de ejemplo, instalar dependencias y restablecer el historial de git. Luego agregaremos una variable de entorno, el punto final GraphQL para nuestra instancia de WordPress, creando un archivo .env.local en la raíz del proyecto.
De acuerdo. Entonces vamos a comenzar con una instancia prácticamente nueva de WordPress que tengo de WPEngine, donde tengo un poco de contenido precargado aquí, incluyendo algunas publicaciones y algunas páginas, para que tengamos algo que realmente consultar aquí. Pero realmente, el punto que estoy tratando de hacer es que realmente no hay nada especial sucediendo aquí todavía. Incluso podemos ver en los plugins que no tenemos ningún plugin instalado, pero nuestro objetivo es, en última instancia, consultar todos estos datos de publicaciones con GraphQL.
Entonces, lo que queremos hacer es instalar ese plugin WPGraphQL para poder hacer eso. Lo primero que voy a hacer es hacer clic en Agregar nuevo en los plugins. Y voy a ir a Buscar, y voy a buscar WPGraphQL, que podemos ver que ya he hecho antes. Y tan pronto como haga esa búsqueda, podemos ver que en el primer lugar está ese plugin WPGraphQL que voy a instalar. Y tan pronto como esté listo, lo activaré. Y podemos ver que tan pronto como se activa, en la barra lateral izquierda ahora tengo esta pestaña GraphQL. E incluso puedo hacer clic en esta página Graphical IDE, donde se cargará y podemos ver que tenemos este editor gráfico. Ahora, como mencioné anteriormente en mi charla, tenemos la capacidad de recorrer en tiempo real todos nuestros datos utilizando este editor de consultas. De esta manera, podemos ver todos los datos que tenemos disponibles, pero también podemos construir nuestra consulta para usarla posteriormente en nuestra aplicación. Ahora, para ver cómo funciona esto, intentemos ver cómo se ven nuestras publicaciones. Entonces, si me desplazo dentro de este panel Explorador, podemos ver que tengo mi publicación aquí, donde si comienzo a abrir eso, podemos ver en la columna central que se está construyendo esa consulta en tiempo real. Ahora, agreguemos algunos datos a eso, donde si comienzo a abrir los bordes y el nodo para esos bordes, ahora podemos ver todos los atributos que realmente tengo para cada una de esas publicaciones. Donde, vamos a tomar algunas cosas que tengan sentido, como la fecha, y tenemos nuestra ID para cada una de las publicaciones. Y qué tal nuestro título para la publicación, donde ahora, si hacemos clic en reproducir, podemos ver que en esta columna de la derecha, ahora tengo todos esos datos para cada una de mis publicaciones. Podemos ver exactamente lo que mostramos en esta página de publicación, pero ahora podemos consultar eso con nuestro WP GraphQL a través del plugin GraphQL. Entonces, ahora veamos cómo podemos tomar estos datos y usarlos para construir una aplicación.
Entonces, lo que vamos a hacer para hacer eso es, porque el inicio de Next.js WordPress que realmente creé es probablemente un poco demasiado complejo para intentar recorrerlo en esta demostración, tengo este ejemplo de inicio más simple, donde realmente es solo una demostración básica de agregar algunas publicaciones a la página. De esta manera, podemos ver cómo se ve consultar los datos en tiempo real y incluso ajustar esa consulta para ver cómo es construir la consulta, modificarla y actualizarla. Entonces, si nos desplazamos hacia abajo en esta página, podemos ver las instrucciones sobre cómo comenzar con esto, que en realidad va a ser similar al inicio de Next.js WordPress, donde vamos a copiar este comando de creación de yarn, donde vamos a usar create next app para hacerlo. Entonces, si voy a mi terminal y pego ese comando, y llamemos a esta aplicación mi-graphql-galaxy, y lo que esto va a hacer, si no estás familiarizado con create next app, es que primero va a clonar básicamente este proyecto de ejemplo que tengo aquí. Luego va a instalar todas las dependencias, e incluso va a restablecer el historial de git. Básicamente, nos va a preparar de inmediato para comenzar y ser productivos con nuestra aplicación. Ahora podemos ver que está listo. Voy a ir y cd a ese directorio, y podemos ver que en realidad tenemos un paso más antes de intentar poner en marcha esta página, donde necesitamos agregar una variable de entorno, y esto va a ser nuestro punto final graphql para nuestra instancia de WordPress. Como podemos ver en la convención de next.js, vamos a agregar este archivo .env.local. Primero voy a abrir mi editor de código con mi nuevo proyecto, y en la raíz del proyecto voy a crear un nuevo archivo llamado .env.local,
7. Consulta de datos de WordPress con GraphQL
Instalamos WPGraphQL para consultar datos de WordPress con GraphQL. Actualizamos la consulta de GraphQL en nuestra aplicación para incluir el autor de cada publicación. Al pasar la consulta actualizada como props, pudimos mostrar el nombre del autor en cada publicación. Esto demuestra el poder de utilizar GraphQL y WordPress para consultar relaciones complejas y acceder a datos.
y aquí dentro voy a agregar esa variable de entorno. Ahora, volviendo a las instrucciones, voy a copiar y pegar eso justo aquí, y a continuación, no queremos intentar consultar tuhost.com, queremos consultar nuestro punto final de GraphQL de WordPress, y ese punto final va a ser, por defecto, básicamente donde se haya instalado tu instancia de WordPress seguido de /GraphQL. Por ejemplo, si abro mi espaciojellydemo.wpengine.com/GraphQL, podemos ver que aunque obtengo un error aquí, podemos ver que este es un punto final de GraphQL funcional. Así que voy a tomar la misma URL y la voy a pegar en mi variable de entorno, donde ahora podemos ver que tenemos este punto final de GraphQL de WordPress configurado con mi URL real. Y ahora intentemos iniciar nuestro servidor de desarrollo ejecutando yarn dev, y podemos ver que inmediatamente se va a iniciar un nuevo servidor apuntando a localhost puerto 3000. Y si intento abrir eso en mi navegador, podemos ver que next.js comenzará a compilar esa página, donde básicamente, está descargando esa información para nosotros y va a construir esa página en tiempo real. Así que ahora podemos ver que tengo mi nueva publicación de blog, mi página de blog, es decir, mi sitio web de blog, y podemos ver que si comenzamos a desplazarnos hacia abajo aquí, tenemos todas esas publicaciones que vimos dentro de WordPress, pero ahora las estamos obteniendo dentro de la aplicación dentro de nuestro navegador. Así que ahora podemos ver que tenemos cada uno de los títulos, y tenemos una descripción, e incluso tenemos un enlace para cada una de nuestras publicaciones, pero queremos agregar un poco más de contexto a esto. ¿Qué tal si queremos agregar el autor a cada una de estas publicaciones? Primero, vamos a sumergirnos en el código para ver cómo se está haciendo esto. Así que voy a volver a mi editor de código, y voy a ir particularmente a source pages index.js, que va a ser nuestra página de inicio, y si vemos aquí arriba, si ya estás familiarizado con React, realmente no hay nada especial sucediendo aquí. Realmente tenemos nuestro componente de inicio que recibe dos props, y lo renderiza en la página. Pero lo que es especial es si nos desplazamos más allá de ese componente React, tenemos esta función que estamos exportando llamada get static props, que es la forma de Next.js de obtener datos que van a ser estáticos para nuestra aplicación en tiempo de compilación, donde podemos ver que estamos obteniendo nuestro cliente Apollo, y estamos construyendo esta consulta de GraphQL, donde estamos obteniendo algunas configuraciones generales para nuestro sitio web, pero también estamos obteniendo todas esas publicaciones, tal como vimos que hicimos antes en el Editor de Graphql. Finalmente, una vez que tenemos esos datos, simplemente los vamos a limpiar un poco, y también vamos a construir la ruta en la que cada una de las publicaciones estará disponible, y luego simplemente los vamos a pasar como props, que nuevamente, si nos desplazamos hasta la parte superior de la página, podemos ver esas props de página y publicación que estamos pasando directamente al componente React. Y luego en ese punto, es como cualquier otro componente React, donde estamos obteniendo esas publicaciones, estamos iterando a través de ellas, y podemos renderizar cada una de ellas dentro del DOM, donde luego tenemos nuestro sitio de blog de demostración de Space Jelly. Así que ahora, como dije, queremos agregar ese autor. Primero voy a tomar esa consulta de Graphql existente que vimos aquí, la que estamos usando activamente en este proyecto, y voy a pegarla en mi Editor de Graphql aquí, voy a hacer clic en Printify aquí, solo para corregir la indentación, pero voy a hacer clic en Play, y podemos ver que estos son exactamente los datos que estamos obteniendo y pasando a la aplicación. Vemos que tenemos todas las publicaciones, incluso obtenemos el extracto aquí, pero también obtenemos ese título y descripción, que podemos ver en la parte superior que estamos mostrando. Así que ahora, aunque tenemos toda esta otra información para nuestras publicaciones, queremos agregar también el autor a eso. Así que vamos a encontrar esa sección de publicaciones, que está aquí, tenemos nuestras publicaciones, y para cada uno de esos bordes en el nodo, también queremos agregar el autor. Así que simplemente voy a comenzar a abrir ese autor, consultar el nodo para cada uno de esos autores, luego podemos ver que obtenemos todos los atributos del autor real en la publicación, o en este caso, probablemente queremos obtener el ID, ya que eso es algo que generalmente queremos tener para cada uno de nuestros nodos, pero luego queremos obtener también el nombre, que si hacemos clic en reproducir ahora, y comienzo a desplazarme hacia abajo en los datos recibidos, podemos ver que ahora vemos el autor para cada una de estas publicaciones, que en este caso particular, soy yo. Vemos a Colby Fayok aquí, pero pudimos ver lo fácil que fue pegar nuestra consulta existente, actualizarla, donde ahora, tan fácilmente como la pegamos, copiemos esto, y peguémoslo de nuevo en nuestra aplicación. Ahora vamos a corregir la indentación allí. Acabamos de actualizar la consulta dentro de nuestra aplicación, y para ver que esto está funcionando, voy a imprimir en la consola la prop de publicaciones real aquí, donde si vamos dentro de nuestro navegador, voy a actualizar la página, y lo escribí incorrectamente allí, así que en lugar de console logs, solo hay uno de ellos, pero podemos ver cuando la página se recarga y se vuelve a compilar, tenemos esta matriz de data, que son todas nuestras publicaciones, pero ahora tenemos esta propiedad de autor aquí, donde si comienzo a expandir todo, entonces podemos ver mi nombre, KolbyFayal. Así que ahora vamos a agregar esto a nuestra página, así que voy a bajar dentro de este componente react, donde justo debajo del título, vamos a agregar una nueva etiqueta de párrafo, y vamos a decir adiós, y vamos a agregar nuestro nombre de usuario, voy a cerrar esta etiqueta de párrafo, pero vamos a especificar el post.author.node.name, y solo para mi cordura, el node.author.node.name. Así que vamos a ver si eso funciona. Así que ahora, si volvemos a cargar la página, y en realidad probablemente debería haberse recargado rápidamente, podemos ver que tengo Bye KolbyFayal allí. Y por supuesto, el espaciado probablemente no es el mejor, podemos solucionar el estilo más tarde, pero podemos ver lo fácil que fue actualizar nuestra consulta, simplemente agregar un poco de data a eso actualizando esa consulta de GraphQL y pudimos tenerlo disponible de inmediato en esa prop de publicación que acabamos de pasar directamente a la aplicación, y pudimos hacer eso porque ahora tenemos el poder de consultar esas relaciones complejas, incluso las categorías si queremos, utilizando GraphQL y WordPress. Muy bien, así que vamos a recapitular lo que logramos aquí. Primero tomamos una instancia existente de WordPress, y instalamos WPGraphQL. Una vez que eso estuvo listo, pudimos ver lo fácil que fue
8. Flexibilidad de WordPress con GraphQL
Creamos una nueva aplicación que aprovecha las consultas con GraphQL, mostrando la flexibilidad de WordPress cuando se combina con GraphQL. Es una opción convincente para la gestión de datos, proporcionando soluciones poderosas y una gran experiencia para usuarios y desarrolladores. Echa un vistazo a Next.js WordPress Starter en GitHub y a mi curso, eCommerce en Jamstack, en leveluptutorials. Encuéntrame en Kolbifeok para obtener más información o hablar sobre la charla.
puedes consultar todos esos datos de WordPress con GraphQL. Finalmente, creamos una nueva aplicación que aprovecha las consultas con GraphQL, y luego agregamos información adicional en la parte superior y con la interfaz de usuario. El objetivo aquí no era que todos ustedes cambien a WordPress, sino mostrar la flexibilidad de esta plataforma y por qué sigue siendo una opción convincente para una solución de gestión de datos cuando se combina con GraphQL. Podemos crear soluciones muy poderosas que brindan una gran experiencia tanto para nuestros usuarios como para nuestros desarrolladores.
Si quieres ver mi trabajo, Next.js WordPress Starter es completamente de código abierto en mi GitHub, y si quieres aprender cómo hacer todo esto en la práctica, puedes consultar mi curso, eCommerce en Jamstack, en leveluptutorials. Y eso es todo. Si quieres obtener más información o hablar sobre la charla, puedes encontrarme en todas partes como Kolbifeok. También tuitearé algunas cosas
9. WordPress y el Desarrollo Moderno
WordPress funciona con arquitecturas de desarrollo modernas, aunque no todos los plugins son compatibles para trabajos personalizados. La mayoría de los sitios de WordPress funcionan bien con WP GraphQL.
que has visto aquí hoy. Gracias a todos. Comenzaremos primero con la pregunta que hiciste, y veremos cómo la gente votó en esa pregunta. Así que, para resumir, la pregunta fue, ¿funciona WordPress con arquitecturas de desarrollo modernas? Y es increíble si ves los resultados. Es, como, 100% sí. Todos votaron por sí. ¿Lo esperabas? Supongo que esa pregunta era un poco obvia. No, no lo esperaba. Creo que, en su mayor parte, funciona con todos los sitios, ¿verdad? Pero los plugins, por ejemplo, no todos los plugins van a ser compatibles, especialmente si estás haciendo trabajos muy personalizados con WordPress. Pero, en general, la mayoría de los sitios de WordPress funcionarán bastante bien con WP GraphQL.
Integración de WordPress y GraphQL
Comencé en la era de los CMS sin cabeza y no sabía mucho sobre WordPress. Tengo algunas preguntas para ti. ¿GraphQL admite bloques de WordPress? En general, no lo admite de forma nativa, pero hay un plugin que puede extraer el contenido. WP GraphQL funciona con la mayoría de los sitios web de WordPress, pero algunos trabajos personalizados pueden no funcionar de inmediato. Es amigable para los desarrolladores y funciona bien con plugins como campos personalizados avanzados y tipos de publicaciones personalizadas. Desde una perspectiva de rendimiento, GraphQL y la API REST tienen sus ventajas y consideraciones.
Esto es interesante, porque es algo que incluso yo no sabía mucho, para mí. Comencé en la era de los CMS sin cabeza. Entonces, realmente no sabía mucho sobre WordPress. Definitivamente aprendí mucho.
Así que tengo algunas preguntas para ti, y la primera es, ¿GraphQL admite los bloques de WordPress? Sí, eso es interesante porque eso es lo que su nuevo editor está usando en este momento. Desafortunadamente, no lo admite de forma nativa en este momento. Es porque la forma en que Gutenberg está creado no guarda el contenido dentro de la base de datos de WordPress como lo haría el contenido tradicional de WordPress. Pero hay un plugin que, según entiendo, hace eso, donde extraerá el contenido, supongo. No estoy muy familiarizado con él. No lo he usado, pero sé que hay alguna solución al respecto. Pero, en general, la mayoría de las veces, utilizarás la cadena HTML que se renderiza desde WordPress.
De acuerdo. Así que hemos encontrado una solución para casi todo. Siempre hay una forma. Si estás decidido, siempre hay una forma. Bien. Solo quería saber, hablaste de WP GraphQL. Entonces, ¿funcionará con cualquier tipo de sitio web de WordPress? Sí, en general, sí. Lo complicado es que a veces hay mucho trabajo personalizado que puedes hacer con WordPress, ¿verdad? Debido a la naturaleza de WordPress, es amigable para los desarrolladores, donde puedes hacer muchas cosas diferentes y personalizarlo según tus necesidades. Y muchas de esas cosas personalizadas... Bueno, no debería decir muchas de esas cosas personalizadas. Algunas de esas cosas personalizadas pueden no funcionar de inmediato, ¿verdad? Pero dicho esto, debido a cómo WP GraphQL está conectado al núcleo de la base de datos de WordPress, muchas de esas cosas deberían funcionar sin problemas, incluidos muchos de los plugins con los que ya puedes estar familiarizado, como campos personalizados avanzados o tipos de publicaciones personalizadas, ese tipo de cosas. Eso es interesante. Definitivamente. Así que hemos hablado... Estamos hablando mucho sobre GraphQL y todo, y anteriormente... Y también usamos la API REST en algunos de nuestros proyectos. Así que quería saber tu perspectiva sobre qué piensas desde el lado del rendimiento. Así que hablaste sobre el rendimiento en la charla. Así que
Rendimiento de GraphQL vs API REST
GraphQL te permite seleccionar solo los datos necesarios, reduciendo las descargas innecesarias en el navegador. Realizar solicitudes REST adicionales puede acumularse, mientras que una sola solicitud GraphQL realiza un solo viaje. Sin embargo, el rendimiento depende del escenario específico y es importante probar y encontrar la mejor solución. La flexibilidad de GraphQL lo convierte en una excelente herramienta para las relaciones de datos.
como... ¿Qué piensas sobre el rendimiento al pensar en el uso de las API de GraphQL en comparación con el uso de las API REST... O mientras se usan las API REST? Sí. Y creo que hay un pequeño detalle en mi respuesta, porque cada situación es diferente. Pero creo que realmente... Algunos de los beneficios de poder usar GraphQL son en primer lugar, puedes seleccionar solo la información que necesitas, lo que realmente reduce en algunos casos en los que algunas API REST simplemente te dan un montón de datos. Y si estás obteniendo eso, esos son bytes adicionales que esa persona tiene que descargar en el navegador. Pero además de eso, si estás haciendo solicitudes REST adicionales, como mostré en la charla, esas solicitudes de red también se acumularán, ¿verdad? Mientras que una sola solicitud GraphQL solo hará ese viaje. Pero nuevamente, como siempre... Realmente depende, ¿verdad? Porque si solo estás haciendo una simple solicitud de API REST, y esa API REST ya te está dando datos limitados, por supuesto que podría ser más rápido que esa consulta GraphQL en tu escenario particular. Por lo tanto, es muy importante siempre probar esas cosas e intentar asegurarte de obtener la mejor solución para ti. Pero GraphQL en general es tan flexible en su naturaleza. Es una herramienta tan excelente para poder usar en las relaciones de datos. Sí. Es increíble. De hecho, cuando comenzamos hoy en la conferencia, le preguntamos a la audiencia qué es lo que más les gusta de GraphQL. Y su respuesta fue definitivamente que la mayoría de las personas votaron por... Obtener la capacidad de elegir lo que quieres obtener de él. Como no obtener todo el montón de datos, sino obtener lo que quieres, lo que estás solicitando. Así que eso es definitivamente un gran punto. Y sí, siempre depende del escenario. El rendimiento es subjetivo y siempre dependerá definitivamente de los escenarios. Así que muchas gracias, Colby, ha sido un placer hablar contigo y aprender de ti. Fue una charla increíble. Realmente aprendí muchas cosas nuevas y estoy seguro de que la audiencia disfrutó mucho. Ahora vamos a tomar un descanso, pero antes de eso, no olvides unirte a Colby en la sala de oradores en el chat especial. Muchas gracias, Colby, fue realmente genial tenerte con nosotros. Sí, muchas gracias a ti y a Git Nation, lo aprecio. Me lo pasé muy bien. Gracias.
Comments