La arquitectura headless cambia este modelo al desvincular el backend del frontend. El CMS act\u00faa como backend, conect\u00e1ndose a una plataforma diferente para mostrar interfaces y contenido amigables al usuario en el frontend. Algunas de las tecnolog\u00edas de frontend m\u00e1s populares que los desarrolladores usan para implementaciones headless incluyen React, Angular, Next, Vue, Faust y Gatsby.<\/p>\n\n\n\n
Bajo este modelo, WordPress se convierte en un centro de contenido, exportando datos al frontend exponiendo una interfaz de programaci\u00f3n de aplicaciones (API) que cualquier tecnolog\u00eda de frontend puede utilizar.<\/p>\n\n\n\n
Headless WordPress es una oferta relativamente nueva. Sin embargo, ya est\u00e1 atrayendo atenci\u00f3n por su potencial para ofrecer flexibilidad a los desarrolladores en sus elecciones de frontend y la escalabilidad de gestionar m\u00faltiples canales desde el mismo backend.<\/p>\n\n\n\n
\u00bfQu\u00e9 es GraphQL?<\/h2>\n\n\n\n![\"Logo](\"https:\/\/wcanvas.com\/wp-content\/uploads\/2023\/09\/wordpress-graphql-1-1024x439.png\")
<\/figure>\n\n\n\nGraphQL es un lenguaje de consulta de c\u00f3digo abierto creado por Meta en 2012. Se utiliza principalmente para crear APIs vers\u00e1tiles y eficientes, emergiendo como una alternativa a la arquitectura REST para APIs.<\/p>\n\n\n\n
Aunque tanto REST como GraphQL hacen solicitudes HTTP a trav\u00e9s de URLs y reciben un archivo JSON como respuesta, tienen diferentes enfoques para proporcionar la informaci\u00f3n a los usuarios. Mientras que REST especifica los recursos disponibles en la API mediante esas URLs, GraphQL estructura los datos en esquemas.<\/p>\n\n\n\n
Los esquemas definen objetos, los campos en esos objetos y los tipos de datos que esos campos pueden contener usando el Lenguaje de Definici\u00f3n de Esquemas de GraphQL (SDL). Aqu\u00ed hay un ejemplo de un esquema de GraphQL que define libros y autores:<\/p>\n\n\n\n
type Book {\nid: ID\ntitle: String\nauthors: []\n}\n\ntype Author {\nid: ID\nname: String\nbooks: [Book]<\/code><\/pre>\n\n\n\nSi queremos obtener informaci\u00f3n sobre un libro espec\u00edfico, creamos una consulta. Aqu\u00ed es donde brilla una de las principales ventajas de GraphQL: los clientes pueden enviar consultas a un servidor especificando los datos exactos que necesitan, y el servidor responder\u00e1 con un objeto JSON que coincide con la estructura de la consulta. Aqu\u00ed ten\u00e9s un ejemplo de una consulta de GraphQL donde pedimos solo el ID de un libro.<\/p>\n\n\n\n
type Query {\nbook(id:ID!): Book\n}<\/code><\/pre>\n\n\n\nUsando REST, tendr\u00edamos que solicitar toda la informaci\u00f3n en la URL del recurso y luego filtrar la respuesta JSON por el\/los campo(s) que necesitamos. El modelo de GraphQL previene la sobrecarga de solicitudes (recibir m\u00e1s informaci\u00f3n de la que necesit\u00e1s) al darte solo lo que ped\u00eds y ahorra en el uso de ancho de banda, CPU y memoria para transferencias de datos y clasificaci\u00f3n. Esto resulta en un rendimiento generalmente mejor que el de las APIs REST.<\/p>\n\n\n\n
Ventajas de GraphQL<\/h3>\n\n\n\nSin sobrecarga ni escasez de solicitudes<\/h4>\n\n\n\n
Con REST, el servidor determina la estructura de las respuestas, y cada endpoint devuelve su contenido completo. Dependiendo de la solicitud, el contenido del endpoint puede proporcionar m\u00e1s (sobrecarga) o menos (escasez) datos de los que el cliente necesita.<\/p>\n\n\n\n
En cambio, los usuarios de GraphQL solicitan precisamente la informaci\u00f3n que necesitan, evitando gastar recursos innecesarios en obtener m\u00e1s datos de los necesarios o en solicitar datos adicionales con m\u00faltiples llamadas. En este sentido, GraphQL es m\u00e1s eficiente.<\/p>\n\n\n\n
Las APIs de GraphQL tienen un solo endpoint<\/h4>\n\n\n\n
Las APIs REST contienen m\u00faltiples endpoints, cada uno para un recurso espec\u00edfico o una colecci\u00f3n de recursos. En contraste, las APIs de GraphQL tienen un \u00fanico endpoint que acepta todas las consultas y mutaciones (modificaciones de datos en el servidor). Tener un solo endpoint simplifica el desarrollo y el mantenimiento.<\/p>\n\n\n\n
Obtenci\u00f3n de datos de m\u00faltiples recursos al mismo tiempo<\/h4>\n\n\n\n
Las APIs de GraphQL permiten a los clientes obtener datos de m\u00faltiples recursos en una \u00fanica solicitud, haciendo innecesario realizar varios viajes de ida y vuelta al servidor. Esto ahorra el uso adicional de CPU, memoria y ancho de banda.<\/p>\n\n\n\n
Flexibilidad para modificar el esquema de GraphQL a lo largo del tiempo<\/h4>\n\n\n\n
Como los clientes pueden elegir qu\u00e9 campos obtener datos, los desarrolladores pueden cambiar la estructura del endpoint sin afectar las consultas existentes o tener que lanzar una nueva versi\u00f3n de la API.<\/p>\n\n\n\n
Moldeado de datos del lado del cliente<\/h4>\n\n\n\n
Los desarrolladores pueden f\u00e1cilmente transformar o manipular los datos recibidos del servidor GraphQL en su lado (lado del cliente) seleccionando campos espec\u00edficos, cambiando la estructura o combinando datos para adaptar la respuesta a los requisitos exactos de la aplicaci\u00f3n del cliente.<\/p>\n\n\n\n
Tipos fuertes<\/h4>\n\n\n\n
GraphQL emplea un sistema de esquemas fuertemente tipado que define la estructura de los datos y las operaciones disponibles que pod\u00e9s realizar sobre ellos. Esto permite la validaci\u00f3n y documentaci\u00f3n autom\u00e1tica, lo que facilita a los desarrolladores comprender e interactuar con la API.<\/p>\n\n\n\n
Desventajas de GraphQL<\/h3>\n\n\n\nGraphQL tiene una curva de aprendizaje m\u00e1s pronunciada<\/h4>\n\n\n\n
Muchos desarrolladores est\u00e1n familiarizados con las APIs REST y han trabajado con ellas durante a\u00f1os, pero GraphQL es una tecnolog\u00eda relativamente nueva. Los desarrolladores que comienzan a usar GraphQL necesitar\u00e1n aprender un nuevo lenguaje de consulta para usarlo de manera efectiva.<\/p>\n\n\n\n
Soporte de herramientas<\/h4>\n\n\n\n
GraphQL requiere un soporte de herramientas m\u00e1s pesado en el lado del cliente y del servidor que las APIs REST, que los clientes pueden consumir con herramientas simples como cURL o un navegador web. Dependiendo de las necesidades del proyecto, los recursos necesarios para usar GraphQL pueden no valer la pena, especialmente para APIs CRUD simples.<\/p>\n\n\n\n
El almacenamiento en cach\u00e9 es m\u00e1s dif\u00edcil<\/h4>\n\n\n\n
Las APIs REST utilizan HTTP GET por defecto para obtener recursos. GET tiene un comportamiento de almacenamiento en cach\u00e9 bien definido que los navegadores web, CDNs, proxies y servidores web pueden usar. GraphQL, en cambio, utiliza HTTP POST por defecto, complicando el proceso de almacenamiento en cach\u00e9. Los desarrolladores a\u00fan pueden desarrollar soluciones de almacenamiento en cach\u00e9 para GraphQL, pero es m\u00e1s complicado y consume m\u00e1s tiempo.<\/p>\n\n\n\n
El problema N+1<\/h4>\n\n\n\n
Permitir que los clientes soliciten solo los datos que necesitan podr\u00eda causar problemas. Como los clientes determinan la complejidad de la consulta, nada les impide ejecutar todas las consultas de una sola solicitud. Esto podr\u00eda colapsar servidores y aplicaciones. Lo mismo podr\u00eda suceder si una funci\u00f3n causa exploraciones inesperadas de tablas para m\u00faltiples usuarios simult\u00e1neamente.<\/p>\n\n\n\n
Mitigar estos riesgos es completamente posible, y los desarrolladores han creado t\u00e9cnicas para hacerlo, pero el proceso a\u00f1ade complejidad a una implementaci\u00f3n de GraphQL.<\/p>\n\n\n\n
\u00bfC\u00f3mo implementar GraphQL para WordPress sin cabezal?<\/h2>\n\n\n\n![\"\"](\"https:\/\/wcanvas.com\/wp-content\/uploads\/2023\/09\/wordpress-graphql-2-1-1024x623.jpg\")
<\/figure>\n\n\n\nPor defecto, WordPress ofrece una API REST que alimenta el Editor de Bloques y puede interactuar con temas, plugins o aplicaciones personalizadas. Para aprovechar las ventajas de GraphQL para tu backend de WordPress sin cabezal, ten\u00e9s que instalar y activar el plugin WPGraphQL<\/a>.<\/p>\n\n\n\nWPGraphQL extiende la funcionalidad de WordPress exponiendo sus datos y caracter\u00edsticas a trav\u00e9s de un endpoint de GraphQL. Una vez activo, ver\u00e1s un bot\u00f3n de GraphQL<\/strong> en la barra lateral del panel de administraci\u00f3n. Pas\u00e1 el cursor sobre \u00e9l y hac\u00e9 clic en GraphiQL IDE<\/strong>. Esto te llevar\u00e1 al \u00e1rea de pruebas de GraphQL, donde pod\u00e9s escribir consultas para tu base de datos.<\/p>\n\n\n\nUna vez en el \u00e1rea de pruebas, pod\u00e9s experimentar con consultas escribi\u00e9ndolas en el panel del lado izquierdo. Por ejemplo, el siguiente esquema consulta todos los t\u00edtulos de cada publicaci\u00f3n en tu sitio:<\/p>\n\n\n\n
query postsQuery{\n posts{\n edges{\n node{\n title\n }\n }\n }\n}\n<\/code><\/pre>\n\n\n\nEjecut\u00e1 la consulta haciendo clic en el bot\u00f3n \u201cPlay\u201d en la parte superior y obtendr\u00e1s una respuesta como la siguiente en el panel derecho:<\/p>\n\n\n\n
{\n \"data\": {\n \"posts\": {\n \"edges\": [\n {\n \"node\": {\n \"title\": \"T\u00edtulo del Post 1\"\n }\n },\n {\n \"node\": {\n \"title\": \"T\u00edtulo del Post 2\"\n }\n },\n {\n \"node\": {\n \"title\": \"T\u00edtulo del Post 3\"\n }\n }\n ]\n }\n}\n<\/code><\/pre>\n\n\n\nUna vez que WPGraphQL est\u00e1 instalado y activo, pod\u00e9s conectar tu backend de WordPress sin cabezal con cualquier marco de frontend moderno.<\/p>\n\n\n\n
\u00bfDeber\u00edas usar GraphQL para implementaciones de WordPress sin cabezal?<\/h2>\n\n\n\n
Para nuestros desarrolladores en White Canvas, GraphQL ofrece muchos beneficios y pocos inconvenientes, lo que lo convierte en nuestra soluci\u00f3n preferida para implementaciones de WordPress sin cabezal. Para tus propias implementaciones, consider\u00e1 los siguientes factores al decidir si usar GraphQL:<\/p>\n\n\n\n
<\/figure>\n\n\n\nGraphQL es un lenguaje de consulta de c\u00f3digo abierto creado por Meta en 2012. Se utiliza principalmente para crear APIs vers\u00e1tiles y eficientes, emergiendo como una alternativa a la arquitectura REST para APIs.<\/p>\n\n\n\n
Aunque tanto REST como GraphQL hacen solicitudes HTTP a trav\u00e9s de URLs y reciben un archivo JSON como respuesta, tienen diferentes enfoques para proporcionar la informaci\u00f3n a los usuarios. Mientras que REST especifica los recursos disponibles en la API mediante esas URLs, GraphQL estructura los datos en esquemas.<\/p>\n\n\n\n
Los esquemas definen objetos, los campos en esos objetos y los tipos de datos que esos campos pueden contener usando el Lenguaje de Definici\u00f3n de Esquemas de GraphQL (SDL). Aqu\u00ed hay un ejemplo de un esquema de GraphQL que define libros y autores:<\/p>\n\n\n\n
type Book {\nid: ID\ntitle: String\nauthors: []\n}\n\ntype Author {\nid: ID\nname: String\nbooks: [Book]<\/code><\/pre>\n\n\n\nSi queremos obtener informaci\u00f3n sobre un libro espec\u00edfico, creamos una consulta. Aqu\u00ed es donde brilla una de las principales ventajas de GraphQL: los clientes pueden enviar consultas a un servidor especificando los datos exactos que necesitan, y el servidor responder\u00e1 con un objeto JSON que coincide con la estructura de la consulta. Aqu\u00ed ten\u00e9s un ejemplo de una consulta de GraphQL donde pedimos solo el ID de un libro.<\/p>\n\n\n\n
type Query {\nbook(id:ID!): Book\n}<\/code><\/pre>\n\n\n\nUsando REST, tendr\u00edamos que solicitar toda la informaci\u00f3n en la URL del recurso y luego filtrar la respuesta JSON por el\/los campo(s) que necesitamos. El modelo de GraphQL previene la sobrecarga de solicitudes (recibir m\u00e1s informaci\u00f3n de la que necesit\u00e1s) al darte solo lo que ped\u00eds y ahorra en el uso de ancho de banda, CPU y memoria para transferencias de datos y clasificaci\u00f3n. Esto resulta en un rendimiento generalmente mejor que el de las APIs REST.<\/p>\n\n\n\n
Ventajas de GraphQL<\/h3>\n\n\n\nSin sobrecarga ni escasez de solicitudes<\/h4>\n\n\n\n
Con REST, el servidor determina la estructura de las respuestas, y cada endpoint devuelve su contenido completo. Dependiendo de la solicitud, el contenido del endpoint puede proporcionar m\u00e1s (sobrecarga) o menos (escasez) datos de los que el cliente necesita.<\/p>\n\n\n\n
En cambio, los usuarios de GraphQL solicitan precisamente la informaci\u00f3n que necesitan, evitando gastar recursos innecesarios en obtener m\u00e1s datos de los necesarios o en solicitar datos adicionales con m\u00faltiples llamadas. En este sentido, GraphQL es m\u00e1s eficiente.<\/p>\n\n\n\n
Las APIs de GraphQL tienen un solo endpoint<\/h4>\n\n\n\n
Las APIs REST contienen m\u00faltiples endpoints, cada uno para un recurso espec\u00edfico o una colecci\u00f3n de recursos. En contraste, las APIs de GraphQL tienen un \u00fanico endpoint que acepta todas las consultas y mutaciones (modificaciones de datos en el servidor). Tener un solo endpoint simplifica el desarrollo y el mantenimiento.<\/p>\n\n\n\n
Obtenci\u00f3n de datos de m\u00faltiples recursos al mismo tiempo<\/h4>\n\n\n\n
Las APIs de GraphQL permiten a los clientes obtener datos de m\u00faltiples recursos en una \u00fanica solicitud, haciendo innecesario realizar varios viajes de ida y vuelta al servidor. Esto ahorra el uso adicional de CPU, memoria y ancho de banda.<\/p>\n\n\n\n
Flexibilidad para modificar el esquema de GraphQL a lo largo del tiempo<\/h4>\n\n\n\n
Como los clientes pueden elegir qu\u00e9 campos obtener datos, los desarrolladores pueden cambiar la estructura del endpoint sin afectar las consultas existentes o tener que lanzar una nueva versi\u00f3n de la API.<\/p>\n\n\n\n
Moldeado de datos del lado del cliente<\/h4>\n\n\n\n
Los desarrolladores pueden f\u00e1cilmente transformar o manipular los datos recibidos del servidor GraphQL en su lado (lado del cliente) seleccionando campos espec\u00edficos, cambiando la estructura o combinando datos para adaptar la respuesta a los requisitos exactos de la aplicaci\u00f3n del cliente.<\/p>\n\n\n\n
Tipos fuertes<\/h4>\n\n\n\n
GraphQL emplea un sistema de esquemas fuertemente tipado que define la estructura de los datos y las operaciones disponibles que pod\u00e9s realizar sobre ellos. Esto permite la validaci\u00f3n y documentaci\u00f3n autom\u00e1tica, lo que facilita a los desarrolladores comprender e interactuar con la API.<\/p>\n\n\n\n
Desventajas de GraphQL<\/h3>\n\n\n\nGraphQL tiene una curva de aprendizaje m\u00e1s pronunciada<\/h4>\n\n\n\n
Muchos desarrolladores est\u00e1n familiarizados con las APIs REST y han trabajado con ellas durante a\u00f1os, pero GraphQL es una tecnolog\u00eda relativamente nueva. Los desarrolladores que comienzan a usar GraphQL necesitar\u00e1n aprender un nuevo lenguaje de consulta para usarlo de manera efectiva.<\/p>\n\n\n\n
Soporte de herramientas<\/h4>\n\n\n\n
GraphQL requiere un soporte de herramientas m\u00e1s pesado en el lado del cliente y del servidor que las APIs REST, que los clientes pueden consumir con herramientas simples como cURL o un navegador web. Dependiendo de las necesidades del proyecto, los recursos necesarios para usar GraphQL pueden no valer la pena, especialmente para APIs CRUD simples.<\/p>\n\n\n\n
El almacenamiento en cach\u00e9 es m\u00e1s dif\u00edcil<\/h4>\n\n\n\n
Las APIs REST utilizan HTTP GET por defecto para obtener recursos. GET tiene un comportamiento de almacenamiento en cach\u00e9 bien definido que los navegadores web, CDNs, proxies y servidores web pueden usar. GraphQL, en cambio, utiliza HTTP POST por defecto, complicando el proceso de almacenamiento en cach\u00e9. Los desarrolladores a\u00fan pueden desarrollar soluciones de almacenamiento en cach\u00e9 para GraphQL, pero es m\u00e1s complicado y consume m\u00e1s tiempo.<\/p>\n\n\n\n
El problema N+1<\/h4>\n\n\n\n
Permitir que los clientes soliciten solo los datos que necesitan podr\u00eda causar problemas. Como los clientes determinan la complejidad de la consulta, nada les impide ejecutar todas las consultas de una sola solicitud. Esto podr\u00eda colapsar servidores y aplicaciones. Lo mismo podr\u00eda suceder si una funci\u00f3n causa exploraciones inesperadas de tablas para m\u00faltiples usuarios simult\u00e1neamente.<\/p>\n\n\n\n
Mitigar estos riesgos es completamente posible, y los desarrolladores han creado t\u00e9cnicas para hacerlo, pero el proceso a\u00f1ade complejidad a una implementaci\u00f3n de GraphQL.<\/p>\n\n\n\n
\u00bfC\u00f3mo implementar GraphQL para WordPress sin cabezal?<\/h2>\n\n\n\n<\/figure>\n\n\n\nPor defecto, WordPress ofrece una API REST que alimenta el Editor de Bloques y puede interactuar con temas, plugins o aplicaciones personalizadas. Para aprovechar las ventajas de GraphQL para tu backend de WordPress sin cabezal, ten\u00e9s que instalar y activar el plugin WPGraphQL<\/a>.<\/p>\n\n\n\nWPGraphQL extiende la funcionalidad de WordPress exponiendo sus datos y caracter\u00edsticas a trav\u00e9s de un endpoint de GraphQL. Una vez activo, ver\u00e1s un bot\u00f3n de GraphQL<\/strong> en la barra lateral del panel de administraci\u00f3n. Pas\u00e1 el cursor sobre \u00e9l y hac\u00e9 clic en GraphiQL IDE<\/strong>. Esto te llevar\u00e1 al \u00e1rea de pruebas de GraphQL, donde pod\u00e9s escribir consultas para tu base de datos.<\/p>\n\n\n\nUna vez en el \u00e1rea de pruebas, pod\u00e9s experimentar con consultas escribi\u00e9ndolas en el panel del lado izquierdo. Por ejemplo, el siguiente esquema consulta todos los t\u00edtulos de cada publicaci\u00f3n en tu sitio:<\/p>\n\n\n\n
query postsQuery{\n posts{\n edges{\n node{\n title\n }\n }\n }\n}\n<\/code><\/pre>\n\n\n\nEjecut\u00e1 la consulta haciendo clic en el bot\u00f3n \u201cPlay\u201d en la parte superior y obtendr\u00e1s una respuesta como la siguiente en el panel derecho:<\/p>\n\n\n\n
{\n \"data\": {\n \"posts\": {\n \"edges\": [\n {\n \"node\": {\n \"title\": \"T\u00edtulo del Post 1\"\n }\n },\n {\n \"node\": {\n \"title\": \"T\u00edtulo del Post 2\"\n }\n },\n {\n \"node\": {\n \"title\": \"T\u00edtulo del Post 3\"\n }\n }\n ]\n }\n}\n<\/code><\/pre>\n\n\n\nUna vez que WPGraphQL est\u00e1 instalado y activo, pod\u00e9s conectar tu backend de WordPress sin cabezal con cualquier marco de frontend moderno.<\/p>\n\n\n\n
\u00bfDeber\u00edas usar GraphQL para implementaciones de WordPress sin cabezal?<\/h2>\n\n\n\n
Para nuestros desarrolladores en White Canvas, GraphQL ofrece muchos beneficios y pocos inconvenientes, lo que lo convierte en nuestra soluci\u00f3n preferida para implementaciones de WordPress sin cabezal. Para tus propias implementaciones, consider\u00e1 los siguientes factores al decidir si usar GraphQL:<\/p>\n\n\n\n