Desarrollo API-first con WordPress sin cabeza

Hola, React Summit. Soy Matt Landers, jefe de relaciones con desarrolladores en WP Engine. Y en esta sesión, vamos a hablar sobre el desarrollo API-first con headless WordPress. Nuestra agenda es muy sencilla. Voy a hablar un poco sobre lo que vamos a hacer y luego haremos una demostración. Solo tenemos 20 minutos, así que no quiero perder mucho tiempo hablando. Quiero mostrarte cómo hacer realmente el desarrollo API-first con WordPress. Puede que estés pensando, ¿por qué WordPress? Hay muchas opciones diferentes para hacer desarrollo de API. ¿Por qué usaría WordPress? Bueno, una muy buena razón es que el 40% de la web es WordPress y eso está creciendo. Y eso significa que tus usuarios probablemente ya conocen WordPress. Así que se sentirán cómodos en el panel de administración, como tus productores de contenido y especialistas en marketing sabrán cómo moverse en WordPress, lo cual es una ventaja para ti porque ya conocen el software. También es gratuito y de código abierto, así que ¿por qué no aprovechar eso? Y ya hay muchas extensiones integradas en WordPress que lo hacen realmente genial para el desarrollo headless. Y el headless WordPress es increíble, así que no necesitas conocer PHP. Creo que ese es el miedo de algunas personas, como yo no quiero hacer PHP, así que no voy a usar WordPress, especialmente en un evento como este donde todos son desarrolladores de React. Bueno, te alegrará saber que no sé PHP y uso headless WordPress casi todos los días. Soy un desarrollador de TypeScript, JavaScript y paso mi tiempo en Node, TypeScript, Deno, esos tipos de lugares. No hago PHP. Tú tampoco tienes que hacerlo. Para esta sesión, hay algunos recursos disponibles para ti. El código que voy a usar y desplegar en esta sesión se puede encontrar en mi GitHub en matt-lander o slash followa.dev repository. El framework que vamos a usar para el headless WordPress es de WP Engine. Así que si vas al GitHub de WP Engine, verás un proyecto de código abierto llamado headless-framework. Eso es lo que vamos a usar para iniciar nuestros proyectos y comenzar. También puedes ir a developers.wp-engine.com y obtener un montón de recursos de mí y mi equipo sobre headless WordPress y cómo hacer cosas específicas. Vamos a sumergirnos y hacer desarrollo de API con WordPress. Para esta demostración, vamos a construir un sitio que liste diferentes desarrolladores en Twitter a los que podemos seguir. Queremos poder encontrar desarrolladores según el lenguaje que suelen utilizar porque si soy un desarrollador y quiero seguir a otro desarrollador, probablemente estoy buscando a alguien que trabaje en el mismo lenguaje y frameworks o tecnologías que yo conozco para poder obtener más información y aprender más al respecto. Eso es lo que vamos a construir en el sitio. Vamos a utilizar headless WordPress como la plataforma que utilizaremos para nuestra API y también donde nuestros usuarios podrán ingresar los datos para el sitio web. Lo que he hecho es utilizar Local para crear un sitio WordPress en mi máquina local.

Puedes obtener esto en LocalWP.com. Es realmente genial para crear rápidamente sitios en WordPress y trabajar en ellos localmente. Luego puedes subirlos a algún lugar en vivo.

De acuerdo. Ya tengo esto en funcionamiento y también tengo algunos plugins que siempre uso ya instalados. El plugin número uno que siempre uso es WPGraphQL. Debes tenerlo porque necesitas una API sólida cuando vayas a trabajar con WordPress. Ya hay una API REST, pero encuentro que es mucho más fácil usar una API GraphQL, especialmente porque hay tantas relaciones en nuestros datos.

También hay otros dos plugins que realmente convierten a WordPress en una plataforma de creación de API. Eso sería Custom Post Type UI y Advanced Custom Fields. También hay extensiones para esos dos para WPGraphQL que también tengo instaladas, y también tengo instalado el framework headless de WP Engine, que es un plugin.

Veamos qué nos ofrece primero. Si vamos al playground de GraphQL aquí, veremos que podemos hacer llamadas a GraphQL directamente a nuestros datos y obtener contenido. Por defecto, WordPress tiene publicaciones y páginas. Este contenido se muestra como HTML sin formato, como podemos ver aquí. En el frontend y desde una API, eso no es realmente lo que quiero obtener todo el tiempo. Por ejemplo, en este caso, quiero obtener una lista de desarrolladores y algunos datos estructurados sobre ellos. Quiero construir una API que me devuelva los datos en el frontend de la forma en que quiero que se vean.

Entonces, hagamos eso. Lo primero que vamos a hacer es crear ese tipo de contenido personalizado, que en WordPress se llama tipo de publicación personalizada. Lo llamaremos desarrolladores, y nuestra etiqueta en plural será desarrolladores y desarrollador. Veremos por qué necesitamos eso en un segundo. Desplazaremos hacia abajo y nos desharemos de algunas de las cosas predeterminadas que aparecen en esta publicación. Solo queremos el título, y queremos que aparezca en GraphQL. Así que tengo que decirle cómo quiero que aparezca en GraphQL. Voy a agregar ese tipo de publicación. Tan pronto como lo agregue, notarás que ahora hay una sección de desarrolladores en nuestro menú, lo cual es genial. Ahora tengo una forma de ver los desarrolladores que he ingresado. Ahora tengo algunos que ingresé anteriormente, y vuelven a aparecer. Así que no quiero tener que ingresarlos de nuevo.

Pero si hago clic en uno, solo puedo ver el nombre. Esto no es muy útil, ¿verdad? Ahora podemos ir a nuestro editor gráfico y extraer estos datos. Podemos decir 'desarrolladores' y solo obtener el título. Y ahora podemos obtener esos data.

Tenemos el título, pero necesitamos más data que esto. Necesitamos extraer su GitHub, su nombre de Twitter, todas esas cosas. Así que vamos a agregar eso. Vamos a los campos personalizados. Y decimos campos de desarrollador. Puedes ponerle el nombre que quieras. Y luego solo quiero que aparezcan en ese tipo de publicación personalizada de desarrollador, no quiero que aparezcan en mis publicaciones de blog o mis páginas, solo quiero que aparezcan en mi tipo de publicación personalizada de desarrollador. Y luego podemos agregar campos de manera muy sencilla. Voy a agregar un nombre y quiero que aparezca en GraphQL, así que me aseguro de que esté marcado aquí. También quiero agregar Twitter. Así que quiero su nombre de usuario de Twitter, que también será texto. Ahora también quiero saber en qué lenguajes trabajan. Lenguajes. Y haremos una taxonomía. En WordPress, las taxonomías son cosas como etiquetas o categorías. Y para esto, vamos a usar etiquetas. También queremos obtener su blog personal. Esto será una URL. Y veremos cómo se utiliza en un momento. Y queremos obtener su GitHub. Otra vez, otra URL. Y eso debería ser suficiente. Muy bien. Así que vamos a ir al final aquí, y queremos asegurarnos de que esto aparezca en GraphQL de nuevo. Y generalmente prefijo el nombre del grupo de campos con ACF y mi desarrollador, lo que quiera llamarlo. Muy bien.

Vamos a volver al principio y vamos a publicar esto. Ahora volvamos a nuestro editor. Y ahora mira, tenemos todos estos campos y un buen editor para que alguien pueda editar. Así que puedo entrar aquí y decir, bueno, sé que Will también sabe C-sharp. Así que agregaré una nueva etiqueta aquí. Y llamaré a eso. Él no tiene un blog. Y luego estamos bien, podemos actualizar eso. Así que ahora tengo un buen editor. Puedo agregar un nuevo desarrollador y agregar todo eso. Y luego queremos, ahora lo que voy a obtener es una buena API, ¿verdad? Así que si voy a mi IDE gráfico, ahora puedo extraer todo esto. Nombre, y también podemos desplazarnos hacia abajo aquí. Y veremos que van a aparecer en ese grupo de desarrolladores de ACF. Sabes, hay GitHub, nombre, blog personal, Twitter, qué lenguajes tienen, así que vamos a ejecutar esto. Muy bien, bastante genial. Así que ahora estamos extrayendo todos esos data de una manera estructurada. No estamos obteniendo contenido sin procesar como lo hicimos con una publicación, estamos obteniendo contenido real como esperaríamos de una API, ¿verdad? Incluso podemos cambiarle el nombre, así que le daremos un alias, lo llamaremos data en lugar de ACF. Ahora tenemos algo bueno que podemos usar en nuestro sitio web. Así que el siguiente paso es construir el sitio web. Así que vamos a hacer eso.

Para el sitio, vamos a utilizar el framework headless de WP Engine, es un proyecto de código abierto que facilita la conexión a WordPress y la obtención de contenido. Así que vamos a utilizar eso. Si vamos a ese proyecto en GitHub y nos desplazamos hacia abajo, hay un comando npx que puedes ejecutar que configurará ese proyecto para ti. Ya lo he ejecutado en aras del tiempo y lo tengo configurado. Veamos cómo está en este momento.

He eliminado mucho del código base que está ahí, así que hay todo un sitio que muestra publicaciones y tiene un blog. Lo he eliminado y he añadido mi propio CSS y algunos componentes. Así es como se ve el sitio en este momento. Tenemos este modo oscuro genial, que hemos hecho puramente con variables CSS, definitivamente revisa el código si te parece interesante. Y luego, vamos a ver el código y lo que vamos a hacer aquí.

De acuerdo, tenemos este archivo de variables de entorno, donde le decimos al framework dónde está nuestra instancia de WordPress. Por ahora, solo estamos mirando nuestra instancia local, lo cambiaremos cuando lo implementemos en una instancia en vivo. Y luego tenemos nuestro secreto de WordPress headless, que proviene de WordPress en sí. Así que si vuelvo aquí, voy a configuración, puedes ver que el secreto está aquí, no puedes hackearme, esto es local, no podrás ver el real. Puedes intentarlo. De acuerdo, tenemos eso configurado. Y eso significa que el framework está listo, sabe cómo comunicarse con WordPress, solo tenemos que utilizar la funcionalidad del framework para realizar esas llamadas. Así que hagámoslo. Y lo primero que queremos hacer es obtener GQL de Apollo. Y vamos a usar esto para guardar nuestra consulta. Así que diremos obtener todo esto, vamos a tomar eso de aquí que hicimos antes. Y simplemente lo pegamos. De acuerdo, ahora tenemos nuestra consulta, lo cual es genial. Ahora necesitamos hacer la consulta y proporcionarla a la página de inicio. Así que determinemos qué va a necesitar la página de inicio desde el punto de vista del tipo. Vamos a crear una interfaz, home props. Y va a tener un developers, necesitamos pasar desarrolladores. Y será del tipo developers, que ya he definido. Y puedo mostrarte eso.

Aquí mismo, tengo este tipo. Esto se parece exactamente a lo que obtendremos de la consulta. Así que si vas aquí, son los mismos campos, solo escritos en TypeScript. Y luego tengo el array. Y como está bajo esa propiedad data, como tenemos aquí, lo hemos extendido así para los desarrolladores. Muy bien, genial. Entonces eso es lo que vamos a pasar aquí. Así que vamos a darle un tipo, React.fc y pasaremos home props. Y ahora tendremos esos desarrolladores listos para nosotros. Genial.

Adelante y mapeemos esto. Entonces developers.map. Y los pondremos en un componente de tarjeta. Tenemos este componente creado. Lo mostraré en un segundo. Necesitamos una clave, que será developer.data.twitter porque eso debería ser único. Y luego la tarjeta solo espera esas props de desarrollador. Así que vamos a hacer developer.data. Y echemos un vistazo a ese componente rápidamente. Lo importaremos. Y es solo un componente puro que tiene algunos estilos y cosas así para nosotros. No tenemos que escribir todo esto para la demostración. Pero es solo un componente puro que mostrará una tarjeta de cada uno de los desarrolladores.

Entonces estamos recorriendo eso, pero aún no hemos proporcionado datos a esta página de inicio. Estamos usando Next, y podemos hacer que esta sea una página estática si simplemente exportamos getStaticProps. Así que hagámoslo. GetStaticProps, y tiene un contexto. Y vamos a escribir eso, getStaticProps.context. Y luego queremos obtener el cliente Apollo. Así que podemos hacer eso con un método del framework llamado GetApolloClient.

Y simplemente pasamos el contexto. Eso, cuando pasamos el contexto, almacenará la caché de esa consulta en el contexto Así que no terminamos haciendo la llamada varias veces. El framework se encarga de todo eso por nosotros. Y queremos hacer la consulta. Así que vamos a obtener los data de Client.Query. Necesitamos esperar esto, porque devuelve una promesa. Y pasaremos GetAllDevs.

Muy bien, genial. Ahora tenemos nuestros data. Necesitamos devolver eso. Así que vamos a devolver props, que tendrá Developers, y será Data.Developers.Nodes. Y la razón de eso está aquí. Así que volverá como Developers.Nodes. Por eso lo estamos pasando de la manera en que lo estamos haciendo. También queremos pasar Revalidate1 aquí, para que obtengamos constantemente nuevos data a medida que agregamos esos desarrolladores a nuestro sitio headless de WordPress. Y hay otra cosa que quiero hacer aquí, que es hacer una llamada de framework a GetNextStaticProps, y simplemente paso el contexto. Esta es la última cosa que necesito hacer para asegurarme de que se almacene en caché esa consulta. Y voy a importarlo del framework. De nuestra siguiente sección del framework.

Muy bien. Entonces ahora lo que estamos haciendo es obtener el cliente, que ha sido agregado a nuestra aplicación por el framework. Si miramos en esta aplicación aquí, tenemos un proveedor headless, y esto hace toda la magia de asegurarse de que Apollo esté configurado y listo para funcionar. Hacemos la consulta para obtener todos los desarrolladores. Llamamos a este método del framework solo para guardar la caché de Apollo en el contexto. Y luego devolvemos nuestras props, las pasamos a nuestra página de inicio y simplemente mostramos estas tarjetas. Así que veamos si funciona. Actualizamos esto, y ahí están. Tenemos nuestros desarrolladores saliendo de WordPress headless, así que vamos a crear otro solo para mostrar cómo funciona esto. Luego entramos aquí, agregamos uno nuevo, digamos Dan Abramov. Bastante seguro de que esto es solo Dan Abramov...

Podría no serlo. Trabaja en Facebook y conoce React, diría yo. Y esas cosas. Lo publicaremos, volvemos aquí, actualizamos. Tengo que actualizar dos veces. No esta vez. Y ahí está Dan. Muy bien, genial. No era el identificador correcto.

Ahora que tenemos nuestro sitio en funcionamiento, el siguiente paso que queremos hacer es implementarlo y ponerlo en vivo. Estoy emocionado de mostrar un poco de lo que he estado trabajando en WP Engine, que es la plataforma Atlas, donde puedes implementar tu sitio de WordPress y tu front-end de Node, sin importar en qué lo hayas escrito. En este caso, estamos usando NextJS, pero podríamos usar Gatsby o Vue o Angular o lo que sea. Y podemos implementarlo en Atlas. Así que vamos a hacer eso.

Si voy a mi portal de WP Engine, ya tengo este sitio en funcionamiento. Tengo un sitio de WordPress, y ahora solo quiero implementar mi aplicación. Así que voy a Atlas y voy a crear una nueva aplicación. Y simplemente le daré un nombre a la aplicación. Follow a dev. Y vamos a usar nuestro entorno headless que se llamará producción. No necesitamos nada más, ¿verdad? Y luego queremos que follow a dev sea nuestro entorno de WordPress. Lo ejecutaremos en el centro de EE. UU. En nuestra configuración de GitHub, esto se ejecuta en Matt-lander/follow a dev, y está en la rama principal. Y necesitamos darle esa variable de entorno que creamos anteriormente. Justo aquí. Y necesitamos darle la URL de nuestro sitio, que ya lo tengo funcionando aquí. Así que solo necesito copiar esta URL. Ya tengo más desarrolladores configurados. Guardaremos eso. Haremos clic en crear aplicación.

Se implementará, obtendrá nuestro código de GitHub, lo descargará. NPM install, ejecutará un script de compilación, npm run wpe-build es el script que se ejecuta. Y una vez que haga eso, ejecutará next build, que creará todas nuestras páginas estáticas y luego lo implementará donde se ejecutará npm start. Donde lo iniciamos en el puerto 8080. Y luego la plataforma sabe cómo ejecutarlo. Pero una vez que esté en funcionamiento, estará listo para funcionar. Y veremos que eso está construyendo aquí. Y cuando termine, volveremos y estaremos en funcionamiento.

De acuerdo, nuestro sitio está en funcionamiento, está bien. Le hemos dado una URL. También le he asignado un dominio personalizado. Y ahora podemos salir y echar un vistazo. Así que en realidad está en follow-up dev, y viste lo rápido que es. Simplemente se está ejecutando. Es instantáneo. Se está ejecutando de forma estática. Y también hemos agregado más funcionalidad aquí, puedes verlo en el código, pero podemos filtrar por diferentes palabras clave aquí, o diferentes idiomas. Y es súper rápido y rápido. Así que échale un vistazo, revisa el código, revisa Atlas y déjame saber qué piensas.

De acuerdo, antes de terminar, tengo una cosa más que mostrarte. En WPENGINE, hemos estado trabajando para hacer de WordPress sin cabeza un CMS sin cabeza realmente excelente, y parte de eso es mejorar la experiencia del usuario. Probablemente hayas notado que mientras creábamos esos tipos de contenido personalizados, no se sentía muy orientado a sin cabeza. Porque hay muchos campos que simplemente no tenían sentido. Así que hemos estado trabajando en nuestro marco de código abierto, que está aquí. Asegúrate de marcarlo para que puedas seguirlo en algún código para crear un modelador de contenido, que estoy demostrando ahora mismo. Esta es la primera vez que alguien ve esto, pero te permite crear modelos de contenido de una manera mucho más fácil de usar. Podríamos crear ese mismo modelo de contenido, desarrollador, desarrolladores, que creamos anteriormente de una manera mucho mejor. Tenemos diferentes campos que podemos crear, así que podemos poner nuestro nombre como un campo de texto, podemos agregar otro campo para los idiomas, que es un repetidor, por lo que es como una matriz. Podemos crear estos campos y podemos crear este tipo de contenido de una manera muy sencilla y luego también podemos tener una experiencia diferente para nuestros editores, que saldrá pronto. Aún no puedes obtener esto, pero asegúrate de seguir nuestro proyecto para que sepas cuándo estará disponible.

Y finalmente, si quieres estar al tanto de las cosas que estoy haciendo, que mi equipo está haciendo con Headless WordPress, ve a developers.wpengine.com. Puedes unirte a nuestro canal de Slack, donde tenemos mucha gente que está hablando de Headless WordPress y haciendo diferentes proyectos relacionados con ello. También creamos mucho contenido semanalmente. Así que tenemos Headless WordPress Live, donde hacemos programación en vivo en YouTube todos los viernes a la 1PM Central, échale un vistazo. De hecho, construimos este sitio followdev durante una de nuestras sesiones de programación en vivo. Y también tenemos el podcast Decode, así que ven y échale un vistazo. Está disponible en iTunes, Spotify, en todas partes. Pero hablamos de todo, desarrollo de front-end y algunas cosas sobre Headless WordPress también. Así que échale un vistazo. Déjame saber qué piensas y construye cosas geniales con Headless WordPress. ¡Feliz codificación!

De hecho, estoy muy sorprendido por esta encuesta. Esperaba que todos quisieran utilizar GraphQL, pero parece que todavía hay personas que utilizan REST. Me alegra haber hecho esta pregunta, porque es un resultado sorprendente.

Sí, pero piensa que tal vez algunos están simplemente atrapados en el pasado, más o menos. Y no porque no quieran utilizar GraphQL, sino porque toda la infraestructura está realmente ligada a REST en general. Tal vez eso sea una razón. Y también los componentes dependen de REST. Es bastante difícil pasar a GraphQL. Puede serlo. Sí, eso es cierto. Sin duda.

De acuerdo, recibimos un par de preguntas. Y comenzaré con la pregunta de Yuri. Se pregunta acerca de la autenticación en Headless WordPress. ¿Viene incluida de serie o aún debemos integrarnos con servicios de terceros como Auth0 a través de complementos, como se implementó anteriormente en la API REST de WordPress? Bien, WordPress tiene su propio mecanismo de autorización. Si te sientes cómodo con eso, definitivamente puedes usarlo. Lo único que tienes que hacer para hacer solicitudes autenticadas es agregar el token de autorización a la solicitud a WP-GraphQL o a la API REST también.

Entonces, en nuestro complemento que hemos creado, el marco de código abierto, hemos implementado un flujo de autenticación. Es similar a OAuth. Entonces, si accedes a una página en tu sitio de front-end donde necesitas autorización, como un enlace de vista previa, por ejemplo, de alguien que está escribiendo un blog y quiere previsualizarlo antes de publicarlo. Cuando acceden al enlace en el front-end, los redirigirá a WordPress para iniciar sesión, lo cual los redirigirá de vuelta al front-end con un código de acceso. Ese código se intercambiará por un token, y luego puedes usar ese token en tu solicitud para obtener cualquier data que necesites para la autorización. Pero si deseas iniciar sesión con terceros, como iniciar sesión con GitHub o algo así, o Auth0, también puedes hacerlo. No lo he probado, pero es un escenario interesante que debería revisar. Sí. Pero como discutimos anteriormente, también estoy luchando con este token de acceso para asegurarme de que no provenga de un hacker, por ejemplo. Me gustaría codificar o decodificar y ver al usuario real. Esto es algo que ocurre en el backend. Entonces, realmente es algo en lo que tal vez un tercero o WordPress, si lo está haciendo, es algo en lo que realmente vale la pena confiar. Correcto. En ese caso, también podrías usar tu backend para tu frontend. Entonces, si estás utilizando un tercero e integrándolo en WordPress, si necesitabas usar ese token para acceder a data, definitivamente podrías hacerlo. Sí, exactamente. O tal vez una personalización, ¿verdad? Correcto.

Otra pregunta viene de Renee Goretzka. Si tienes consultas anidadas de GraphQL, ¿el complemento recupera los datos en una sola solicitud SQL Genie o realiza varias solicitudes a la base de datos SQL? No estoy cien por ciento familiarizado con el funcionamiento interno de WP GraphQL, pero puedo hacer esa pregunta a Jason Ball, quien está en nuestro equipo y lo mantiene. Diré que es muy eficiente con sus consultas, mucho más eficiente que la API REST. Hay algunas demostraciones que hemos hecho donde golpeamos un servidor con muchas publicaciones y taxonomías como etiquetas y categorías, y tarda, ya sabes, ocho segundos en responder con la API REST. Y luego, cuando usamos la API GraphQL, tarda, ya sabes, 20 milisegundos. Así que es mucho más eficiente que usar la API REST, sin duda alguna.

Sí. Creo que también hay un cargador de datos involucrado, ¿verdad? Y habrá, básicamente, para, aunque estés usando WordPress o no, va a tomar algo o va a unir las solicitudes tal vez. Y sí, otra pregunta. Exactamente. Sí. Sí. Así que optimizaciones.

Otra pregunta viene de Carlos Barraza. ¿Cómo generaste los tipos para las operaciones? Creamos los tipos. Bueno, el complemento viene con tipos estándar. Entonces, si tienes una publicación regular o algo así, esos tipos estarán, el complemento los tiene disponibles para ti. Pero si tienes un tipo de publicación personalizado, deberás proporcionar esos tipos. Probablemente no los viste en la presentación, pero esos tipos estaban allí. O los proporcionas tú.

Otra pregunta viene de Navis. ¿Hay complementos para mejorar el rendimiento? ¿Hablamos anteriormente sobre el rendimiento? Tal vez haya complementos para mejorarlo. Una de las razones por las que optarías por WordPress sin cabeza en primer lugar es por la escalabilidad y el rendimiento. Ya sabes, WordPress tradicionalmente, cuando tienes la representación mezclada con la API y los datos, diferentes complementos hacen cosas diferentes y no tienes mucho control sobre eso. Es un poco difícil escalar WordPress, pero cuando divides la arquitectura en donde tienes la API y el front-end, te brinda muchas más opciones sobre cómo escalar esa plataforma. Entonces puedes hacer caché en la capa de nodo. Entonces, si tienes una publicación que se accede mucho y estás haciendo representación en el servidor o algo así, puedes hacer caché en la capa de nodo y solo comunicarte con WordPress cuando realmente lo necesites. Y también puedes distribuir ese front-end globalmente, lo cual no podrías hacer con WordPress, ya que está tan ligado a la base de datos. Así que hay muchas opciones cuando vas sin cabeza para la escalabilidad, simplemente abriendo esa arquitectura.

Genial. Otra pregunta viene de Marcus Young. En primer lugar, a él o ella le encanta tu presentación. Así que felicidades por eso. Y la pregunta es, ¿también creas paneles personalizados para clientes con este enfoque sin cabeza, o solo usas el panel de WordPress? ¿Paneles personalizados en el lado del administrador, supongo? Creo que sí, ¿verdad? Si ya tienes complementos que estás usando, sí, si ya tienes complementos que funcionan en el lado del administrador, esos seguirán funcionando. Entonces, si tienes algo que funciona desde una perspectiva de panel, diría que te quedes con eso. ¿Por qué reinventarlo? Cuando vas sin cabeza, pierdes todos los complementos que modifican el front-end.

Definitivamente deberías aprovechar todo lo que puedas en el backend para reducir la carga de desarrollo, sin duda. Sí, tiene sentido.

Bueno, llegó una gran pregunta. Es de Giannakis87. ¿Qué hay del complemento de WooCommerce o ya tienes alguna integración más específica para el e-commerce? Sí, WooCommerce tiene APIs que puedes aprovechar. Aún no hemos construido nada específicamente sobre WooCommerce. De hecho, he realizado algunas sesiones de codificación en vivo donde uso Shopify mezclado con WordPress. Así que mezclo contenido y comercio, y en realidad hay una masterclass que es parte de esta conferencia que hicimos la semana pasada. Creo que se volverá a transmitir la próxima semana donde construimos una tienda de e-commerce de Shopify. Pero no sería diferente usar WooCommerce en lugar de eso. Solo queríamos mostrar el uso de diferentes fuentes de datos en eso. Pero definitivamente hay una oportunidad ahí para construir algunas cosas listas para usar para WooCommerce, sin duda.

Otra pregunta, una larga, pero muy buena. La hace CW. Dado que tanto el Frontend estático como WordPress están alojados en WEngine, ¿la instancia de WordPress es accesible públicamente o es una VPC de algún tipo para que puedas acceder al Frontend estático e interactuar con él a través de Apollo? ¿O alguien aún puede llegar accidentalmente al sitio de WordPress? Correcto, por defecto, la instancia de WordPress está disponible en Internet porque muchas personas quieren acceder a ella desde el navegador. Entonces, si vas a hacer cosas del lado del cliente es posible que desees acceder a tu instancia de WordPress desde el navegador. Pero es posible poner tu backend completamente fuera de línea y solo hacerlo accesible desde el lado del nodo si así lo deseas. Una cosa que hacemos en el complemento es quitar el frontend de Internet. Por lo tanto, no está indexado por un motor de búsqueda o algo así. Entonces, si accedieras al frontend de WordPress esa persona sería redirigida al frontend que está en nodo para evitar, ya sabes, múltiples SEO potenciales como ser indexado y también para reducir la superficie de ataque desde un punto de vista de seguridad. Por lo tanto, solo podrían acceder a wp-admin lo cual sería mucho más difícil de vulnerar que algún complemento que esté afectando tu frontend.

Muy bien. Hablando de SEO, Zach Winnie preguntó, ¿hay alguna forma de consultar cosas como etiquetas de encabezado para SEO con WordPress Engine Headless? Sí. Y lo hicimos en nuestro taller de React para esta conferencia. Así que Yoast tiene un complemento para WP GraphQL para que puedas extraer todos los datos de Yoast de WordPress. Y luego Will Johnston, que está en mi equipo en WP Engine, creó un componente de React al que puedes pasar esos datos y simplemente enchufarlo en el componente de React y lo colocará en el encabezado por ti. Lo hará tanto en el renderizado estático como en el del lado del servidor, como prefieras hacerlo también.

Y creo que tenemos tiempo para una pregunta más. Luis Zardon está preguntando, ¿hay alguna forma de crear campos a través de la API en WordPress? ¿Hay alguna forma de crear nuevos campos a través de la API? Esa es una buena pregunta. No creo que de forma predeterminada puedas hacer eso, pero es algo que podrías habilitar fácilmente con WP GraphQL. WP GraphQL es muy extensible y lo he utilizado para crear campos sin duda. Y también, he utilizado la extensibilidad de WP GraphQL para crear un formulario en el que solo puedes enviar datos al formulario, pero no leer los datos del formulario, lo cual es una buena manera de crear, como un formulario de contacto. Es bastante genial.

Y muchas gracias, Matt. Tuvimos muchas preguntas, pero se acabó el tiempo. Y, quiero, pero tal vez la gente aún pueda contactarte. ¿Vas a estar disponible en la llamada? Sí, voy a unirme al chat espacial en un minuto. Así que si quieres unirte allí, estaré allí. Pero también puedes contactarme a través de mi GitHub o Twitter o donde quieras encontrarme. Matt Undershorelander está en Twitter. Increíble. Muchas gracias una vez más, y disfruta el resto del día, Matt. De acuerdo, gracias por tenerme.