Como pasa en el mundo de la farándula, conviene estar atento al mundillo de las especificaciones y herramientas para definir APIs de servicios. Y GraphQL es uno de los que merecen que le prestemos atención.

GraphQL es una especificación, en estado de Working Draft como puede verse aquí.

graph

fuente Graph in the age of REST APis

Desde los tiempos de los RPC (remote procedure call) y antes también, se ha intentado encontrar la panacea para que los programas clientes se puedan comunicar con los servidores de la manera más sencilla y eficiente posible, y esta especificación es una vuelta más de tuerca en este sentido. Tanto, que algunos dicen que es un sustituto de REST.

GraphQL está siendo impulsado por Facebook (creado en 2012 y publicado en 2015) buscando precisamente la eficiencia ya que en esta ocasión los papeles de cliente-servidor se tornan.

Con GraphQL, es el cliente el que le dice al servidor cómo quiere que le devuelvan los datos.

De esta manera, nos podemos ahorrar unas cuantas llamadas en el escenario típico de que primero de piden los datos generales de un recurso y luego se solicitan los detalles.

Precisamente de aquí viene lo del “QL”, es decir, Query Language. Viene a ser como el SQL de los servicios (salvando las distancias claro).

¿Cuáles son sus características principales? En este artículo vemos las 5 características principales

  1. Obtención de datos más elegante
    La idea de esto que con GraphQL evitamos tener muchos endpoints y sobre todo las continuas consultas encadenadas como en el caso de consulta maestro/detalle. Esto es muy importante por ejemplo cuando se está en una red móvil ya que “encapsular” todas las llamadas en una sola suele tener mejor rendimiento.
  2. Mayor estabilidad en el backend
    Aquí se hace referencia a que mayor sencillez implica una mayor estabilidad en el backend. Esto lo tendría que ver ya que no sería la primera vez que algo que “vale para todo”, es decir, que permite varios tipos de consulta en lugar de ser más sencillo resulta que es mucho más complicado que una serie de de servicios con una consulta sencilla cada uno.
  3. Mayor eficiencia en las consultas
    Menos consultas significa más eficencia y menos tiempo de respuesta. Si tenemos en cuenta por ejemplo una red móvil con sus tiempos de latencia, esto normalmente será cierto. Evidentemente, si nos evita tener que hacer varias consultas para conseguir el detalle de varios recursos también mejoraremos la eficiencia.
  4. Es una especificación
    Esto nos da claridad sobre lo que puede y no puede hacer, además de ofrecer una mayor fiabilidad en los servicios al tener un esquema al que atenerse.
  5. Mejora el entendimiento y la organización
    La idea en la que se incide aquí es que se va tener un mayor control, desde el punto de vista del gobierno de los servicios, ya que en un sólo sitio está definidos los servicios de consulta, los tipos de datos, los tipos de error, etc. etc.

Conclusión.

En un primer momento este concepto parece un poco raro. El hecho de que el cliente diga qué tipo de datos y cómo tiene que devolverlos al servidor es una inversión de papeles en toda regla. ¿No rompe esto los principios de SOA de contrato de servicio y abstracción?.

Recuerdo hace algunos años una aplicación web que diseñamos mediante el patrón de comandos, al final hicimos un comando que recibía una consulta SQL y devolvía el resultado al cliente. Al final se convirtió en un saco con todo tipo de consultas más o menos abiertas que prácticamente se escapaban a todo intento de gobernar el API porque los contratos de los servicios ya no estaban bien definidos.

Habrá que darle un oportunidad a GraphQL, plantea otra forma de hacer las cosas muy interesante para mejorar la comunicación cliente-servidor,  pero igualmente, conviene no perder de vista sus peligros desde el punto de vista de SOA.

Anuncios