GraphQL herramientas de backend como servicio

kendru Estrada

Compartir

GraphQL herramientas de backend como servicio

Desde hace un tiempo GraphQL ha venido dando que hablar, se dice que esta nueva forma de comunicarse con el backend reemplazará a los APIs REST (123) de forma parecida como antes se dijo que las APIs REST reemplazarían los webservices SOAP.

Por su popularidad alrededor de GraphQL se ha construido un variado ecosistema de herramientas relacionadas. Hace poco me llamaron profundamente la atención las herramientas que proveen el backend como servicio, estas herramientas buscan acelerar el desarrollo de aplicaciones, construyendo un backend en GraphQL automáticamente a partir de un modelo de datos. Hasta el momento he encontrado 3 herramientas Graphcool, Scaphold y Reindex. Creo que estas herramientas aun cuando son recientes tienen gran potencial de crecimiento ya que aumentan dramáticamente la velocidad de desarrollo de aplicaciones, (por ejemplo Scaphold tiene un tutorial para hacer un backend para el clon de slack en 15 minutos) . Para entender un poco más de este tema hay que entender algunas cosas, como por ejemplo:

Que es GraphQL?

GraphQL es un lenguaje de consultas para APIs., esto significa que GraphQL está diseñado para interpretar una consulta (Un string con un formato definido) enviada por un cliente y retornar los datos requeridos. Para ponerlo en términos sencillos las consultas se parecen mucho a objetos JSON vacíos que se envían a un endpoint único de GraphQL, el cual retorna solo los datos consultados. además GraphQL es el entorno de ejecución para obtener los resultados de estas consultas.

Un ejemplo sacado desde la misma página de GraphQL es el siguiente:

Consulta:

{
hero {
      name
      height
     }
}

Resultado:

{
“hero”: {
         “name”: “Luke Skywalker”,
         “height”: 1.72
        }
}

La idea es que aunque tipo de dato “hero” tenga más campos sólo se obtienen los requeridos.

Además de poder obtener solo los datos requeridos existen otras funcionalidades interesantes, por ejemplo se pueden obtener relaciones del tipo maestro detalle de una sola vez, sin necesidad de realizar varias llamadas como se haría en una API REST, se pueden insertar datos, hacer consultas complejas y hacer validaciones. Puedes conocer todas estas funcionalidades leyendo este excelente manual que está en la página oficial.

¿ …y por que reemplazará a las APIs REST? (¿y que paso con SOAP?)

Para entender porque cada tecnología “reemplaza” a la anterior, hay que entender que es lo que reemplaza y porque lo nuevo es mejor, es muy común decir que estas tecnologías no son comparables ya que existen diferencias notorias, por ejemplo SOAP es un protocolo, REST es un arquitectura y GraphQL es un lenguaje para hacer consultas, sin embargo y a pesar de la dificultad de comparación, es evidente que hasta ahora REST a “reemplazado” a SOAP en la Web ( 5 ) y es posible que en el futuro ocurra lo mismo con GraphQL considerando su tendencia al alza (6). Considerando esto voy a hacer un resumen de cuales creo que son las razones de estos reemplazos.

Los webservices SOAP surgieron de la necesidad de dar interoperabilidad entre aplicaciones, permitiendo a estas comunicarse a pesar de estar escritas en distintos lenguajes, estar corriendo en distintos sistemas y manejar distintos tipos de datos. Sin duda SOAP solucionó los problemas de interoperabilidad y fue un éxito, sin embargo cuando empezaron a aparecer las primeras APIs REST, el mundo se dio cuenta que eran más simples de construir y consumir que los webservices SOAP, por ejemplo, al construir la API REST no se necesitaba un descriptor que definiera las entradas y salidas, los métodos se construían usando los verbos del protocolo HTTP, se usaban los códigos de error de HTTP, y no había que adherirse a alguno de los muchos estándares de interoperabilidad (4) que definieron para los webservices SOAP, además, si se implementa correctamente tenía las ventajas de la arquitectura REST, con la cual es fácil, el escalamiento horizontal, el caching en el lado del cliente, entre otras. Ahora GraphQL está atacando otro problema que surgió luego del éxito que tuvieron las APIs REST, el problema es que para cada API existen muchos endpoints producto de que a veces los verbos HTTP no son suficientes para describir todas las necesidades de combinaciones de datos que se requieren en la vista y, por lo tanto, se crean endpoints “auxiliares” para satisfacer dichas combinaciones de datos. Considerando esto, la gente que creo GraphQL se preguntó:

¿Por que el servidor necesita saber qué datos necesita la vista?

La respuesta a esta pregunta desde GraphQL es que, el servidor NO necesita saber cuales son las necesidades de datos del cliente sino que es el cliente el que a través de un lenguaje de consulta simple describe los datos que necesita.

Genial pero, ¿y dónde va la lógica del negocio?

Esta es una nueva manera de hacer las cosas y esta pregunta no tiene una respuesta tan clara aunque hay algunos enfoques posibles.

Por ejemplo si quiero realizar una acción como enviar un correo cuando se cree un usuario, existen 2 opciones

Monolítico: En el propio backend que se programó en GraphQL, se tiene una función resolve. En esta función se puede realizar la lógica del negocio.

Microservicios; es posible combinar GraphQL con funciones en un plataforma serverless como AWS Lamda y en la función resolve gatillar eventos, los cuales harán que una función lambda se active y realice las operaciones necesarias.

Aun no esta claro cual es la mejor práctica y puede que en el futuro surjan otras opciones considerando que GraphQL aun es nuevo.

Entonces, ¿hay que usar GraphQL?

Como todo en la tecnología es casi una apuesta, hay muchas tecnologías que son populares y luego no tienen el éxito proyectado, sin embargo yo apostaría a que GraphQL va a seguir creciendo y que no será reemplazada en el corto plazo con otra idea, debido a que, el beneficio es muy grande para las aplicaciones clientes, es una buena herramienta de integración y además puede ser un acelerador de los tiempos de desarrollo (usando las herramientas apropiadas) por lo tanto creo que ante tales beneficios es bueno adoptarlo en las empresas que construyan productos de software ya sea aplicaciones móviles o sistemas web.

y ¿Qué pasa con las herramientas de backend as a service?

Esta probablemente sea una apuesta más grande ya que estas herramientas son realmente recientes, pero aún cuando las he revisado muy superficialmente me parece que la idea es genial ya que cuando se desarrollan aplicaciones, el backend es una parte de la aplicación que, en mi opinión no es compleja, pero es tediosa y demora más tiempo del que quisiéramos, además no tiene valor para los clientes. Herramientas como estas permiten enfocarse en lo que realmente da valor a los clientes: la aplicación y las funcionalidades en ella, no en cómo se obtienen y guardan los datos.

Cuando se combinan estas herramientas con funciones lambda siento que las arquitecturas de aplicaciones cambiarán completamente, y para mejor creo que estos herramientas se harán primero populares para productos elaborados por startups y como casi siempre pasa, serán consideradas por las grandes empresas solo cuando estén los suficientemente probadas y maduras.