Desarrollo Web

GraphQL, el futuro de las API

Si bien RESTful y SOAP son APIs que gozan de gran popularidad hoy, GraphQL ha ido sumando adeptos durante los últimos años.

GraphQL fue desarrollado inicialmente por Facebook en 2012, para ser liberado públicamente el 2015 y finalmente el año 2018 ser traspasado a la “GraphQL Fundation”; organización a cargo de la Fundación de Linux. Desde entonces su adopción ha tenido un incremento sostenido que no nos sorprende.

La API del momento

A diferencia de REST, GraphQL se define como un “Lenguaje de Consulta de Datos” open source. En ese sentido, utiliza Schemas para definir entidades de datos, relaciones y el origen de esos datos, que por ejemplo, puede ser otra API o una Base de Datos.

Las preguntas típicas que podrían surgir y que intentaré responder a continuación, son: 

1. ¿GraphQL significa el fin de REST o de SOAP? 
2. ¿Cuál API es mejor, RESTful, SOAP o GraphQL? 
3. ¿Cuál debo usar?
4. ¿Por qué GraphQL es el futuro?

¿GraphQL significa el fin de REST o de SOAP? 

No, no es el fin de RESTful ni de SOAP. Ambas especificaciones son ampliamente usadas hoy en día. En Chile, por ejemplo, podríamos decir que una de las plataformas más usadas por el comercio es Transbank, y en consecuencia, su API en SOAP también lo es. 

RESTful también goza de gran popularidad en la comunidad de desarrolladores. Casi todas las grandes empresas cuentan con API’s en REST. Hablamos de redes sociales o herramientas como Twitter, Medium, Google y así, un largo etcétera. 

En el caso de REST, WordPress merece una mención especial, porque además de ser uno de los Sistema de Gestión de Contenidos (CMS) más utilizado, desde hace unos años, ha hecho una implementación nativa de RESTful que es extensible y personalizable para distintas necesidades de uso. Por lo que ha impulsado el uso de API RES. Nosotros en IDA, usamos intensivamente esta capacidad para generar nuestros propios endpoints.

¿Cuál API es mejor: RESTful, SOAP o GraphQL? 

En ese contexto tampoco creo que una especificación sea mejor que otra. Creo más bien, que según el contexto de uso puede ser mejor usar uno u otro tipo de API. Dicho de otra forma, si analizamos el requerimiento podemos atender a ciertas ventajas y desventajas respecto de utilizar una u otra implementación.

Por ejemplo, si en el proyecto que desarrollaremos necesitamos un uso acotado, cuando tenemos que procesar un formulario, almacenar un set de datos en la base de datos, gatillar el envío de un email tipo y responder en pantalla con un mensaje estándar; podría desarrollarse rápidamente en REST sin grandes complicaciones. Hablamos de un uso acotado y restringido, en el que solo necesitamos un endpoint y una respuesta estándar. 

Por el contrario, si nuestro proyecto es más ambicioso y queremos construir todo un Theme de WordPress basado en Vue.js o Angular; el que implicaría un uso intensivo de muchos endpoints de una API y donde necesito distintas respuestas para distintas interfaces, entonces me plantearía utilizar GraphQL, dado que las ventajas de su Lenguaje de Queries (de ahí el QL de su nombre), nos puede simplificar y ordenar mucho el desarrollo del backend que proporciona los datos que necesitamos para cada interfaz.

Entonces ¿cuál debo usar?

Aquella que te permita hacer más con menos y en menos tiempo. La que, además, debe ser acorde al requerimiento que tenemos.

Reitero en el ejemplo, si en mi proyecto no tengo grandes requerimientos de integraciones y uso de API, pero tengo que procesar uno o dos formularios, elegiría RESTful. 

Con el siguiente código, podríamos tener lo básico para cumplir lo que necesitamos.

register_rest_route('guardar', 'contacto', array(
 'methods' => 'POST',
 'callback' => 'guardar_contacto',
 'permission_callback' => '__return_true',
 'args'=> array(
  'field_5c63337b5fc7f' => array('required'=>true, 'type'=>'string'),
  'field_5eea92a63c785' => array('required'=>true, 'type'=>'string'),
  'field_5eea92a63c98e' => array('required'=>true, 'type'=>'string')
  )
));

function guardar_contacto(WP_REST_Request $request){
$data = $request->get_params();
$contacto_id = wp_insert_post(
array(
'post_title' => 'Contacto de ' . $data['field_5c63337b5fc7f'],  //campo nombre 
'post_content' => '',
'post_status' => 'draft',
'post_type' => 'contacto', 
)
);

if (!$contacto_id || is_wp_error($contacto_id)) :
wp_die('Error al crear contacto');
endif;

update_field('field_5c63337b5fc7f', $data['field_5c63337b5fc7f'], $contacto_id); //campo nombre 
update_field('field_5eea92a63c98e', $data['field_5eea92a63c98e'], $contacto_id); //campo email 
update_field('field_5eea92a63c785', $data['field_5eea92a63c785'], $contacto_id); //campo mensaje 

$return = send_email_contacto($data['pid']);
$response = get_field('respuestas', $data['pid']);

if ($return) :
$response = $response['exito'];
$response_html = load_template_part('partials/forms/response-exito');
$status = 'success';
else :
$response = $response['error'];
$response_html = load_template_part('partials/forms/response-error');
$status = 'error';
endif;

return array(
'status' => $status, 
'response_html' => $response_html
);
}

En el ejemplo, con pocas líneas de código, hemos creado 1 endpoint que recibe 3 campos de formularios con nombres específicos, donde solo es posible guardar los campos personalizados como un post de borrador en el post type contacto. El sistema mandará un email con formato y texto predefinido y devolverá un status y una respuesta también predefinida para presentar en pantalla.

Pero ¿Cuán seguro es?

El factor seguridad es una consideración importante que me ayuda a tomar una decisión. En el ejemplo anterior, podría verificar el wp nonce y tomar algunas decisiones básicas de seguridad extra, agregando un par de líneas. No obstante, el endpoint programado, al ser muy específico y acotado, no permite que algún bot intruso y mal intencionado se ponga a hurgar donde no queremos que lo haga.

GraphQL -para el caso del requerimiento anterior- pareciera excedernos con creces en capacidades y complejidades. Y es que las lógicas detrás de GraphQL son distintas.

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.

GraphQL se define como un lenguaje de consultas al que podemos responder con data existente. En el caso de WordPress, por ejemplo, nuestra “data existente” son los distintos objetos y APIs internas del mismo WordPress. Como los settings u opciones de WordPress, los Users, los Posts, las Pages, las Taxonomías, etc. 

Así podríamos consultar por un Custom Post Type llamado evento en una cantidad de los primeros 2 eventos creados y donde solo queremos los campos id, eventoId, title y date. 

Cuya respuesta podría verse más o menos así:

Es decir, es una especie de abstracción de la clase WP_Query, pero al mismo endpoint podríamos consultarle por el userId y el name de los Users.

Con los ejemplos anteriores es fácil prever lo simple que sería construir un Theme de WP donde toda la interfaz pública se podría hacer en base a GraphQL y Javascript. En este caso, sólo tendríamos que realizar una o varias consultas según las necesidades de cada vista, sus componentes y módulos.

¿Y el formulario del ejemplo se podría hacer? 

Claro que sí y sería igualmente simple. Del mismo modo que en las API Rest no empleamos llamadas GET para crear o actualizar entidades (usamos POST, PUT o UPDATE); en GraphQL esas operaciones las hacemos a través de mutations.

Según la documentación de GraphQL debemos entender por mutation a una operación que provoca cualquier tipo de cambio en el estado del servidor. 

Un ejemplo muy básico para hacerse cargo solo de guardar los campos del formulario podría ser así:

mutation {
  createContactForm(input: {
 'field_5c63337b5fc7f': "Max Villegas", 
 'field_5eea92a63c785': "info@ida.cl", 
 'field_5eea92a63c98e': "Hola! Este sería el mensaje"
 }) 
 {
    id
  }
}

Más info en https://docs.wpgraphql.com/extending/mutations/

Si bien es cierto que se ve muy simple, al menos en el caso de WP, para hacer esta implementación sería necesario disponibilizar públicamente una serie de Schemas que realmente no queremos o no necesitamos exponer, pues aumentan las posibilidades de que los bots hurguen en nuestra API buscando información potencialmente sensible.

Hoy una forma sencilla de implementar GraphQL es mediante plugins como WPGraphQL. En caso contrario, tendrías que desarrollar tu propia implementación desde cero, con lo que la complejidad inicial obviamente aumenta.

¿Entonces por qué GraphQL es el futuro?

Básicamente porque en desarrollos complejos, que requieren de muchos endpoints para obtener los datos necesarios para construir las distintas interfaces, y donde cada pequeña variación puede implicar crear un nuevo endpoint; GraphQL nos permite simplificar y ordenar, dejando que el cliente decida qué necesita y qué no, a la hora de hacer la consultas de información. 

Según graphql.org, las ventajas principales se resumen en 3 premisas:

1. Pide lo que necesitas y consíguelo exactamente así.
2. Consigue muchos recursos en una petición única 
3. Describe qué es posible con definiciones de tipo

Pide lo que necesitas y consíguelo exactamente.

Cuando envías una query a la API recibes exactamente lo que necesitas, nada más ni nada menos. Las consultas de GraphQL siempre devuelven resultados predecibles. Las aplicaciones que usan GraphQL son estables y rápidas porque ellas, en cuanto cliente, controlan la data que necesitan (o no) del servidor.

Consigue muchos recursos en una petición única 

Las consultas de GraphQL acceden no sólo a las propiedades de un recurso, sino que pueden seguir referencias entre recursos distintos (posts y users). Mientras una API en  REST requiere cargar información de múltiples URL, GraphQL consigue toda la información en un único Request. Aplicaciones que usan GraphQL pueden ser rápidas incluso con  conexiones lentas 

Describe qué es posible con definiciones de tipo

GraphQL está organizada en términos de tipos y campos no de endpoints. Puedes acceder a todas las capacidades de tu data en un único endpoints. Al usar tipos las aplicaciones solo pueden hacer consultas de los datos que son posibles, obteniendo errores claros y útiles en caso de consulta por datos no disponibles. A la vez que las aplicaciones no necesitan “parsear” manualmente un set de datos para obtener solo lo que necesitan.

Un desarrollo menos complejo

En conclusión, con GraphQL podemos simplificar el trabajo de desarrollo y dejar a la capa front muchas de las decisiones acerca de qué datos solicitar al backend para desplegar en las interfaces que construimos.

Sin embargo, esta no es nuestra única opción y a veces, la mejor opción para nuestro requerimiento, será utilizar una api RESTful o SOAP. Utilizar la mejor alternativa dependerá de quée tu proyecto necesite.