Descubre las diferencias entre GraphQL y REST

REST; hasta las grandes ideas envejecen

Quienes nos dedicamos a crear arquitectura web, regularmente usamos API REST para vincular funcionalidades a la interfaz. Nos encanta la facilidad con la que REST permite a sistemas y software comunicarse entre sí para obtener, por ejemplo, una experiencia digital de calidad.

Lamentablemente, REST se ha visto sobrepasado por los cambios y exigencias en los requerimientos desde el lado del cliente. No permite optimizar la selección y transferencia de información, lo que genera los problemas de over-fetching & under-fetching.

Dicho de otra manera, en tu consulta obtienes más o menos de los datos solicitados, generando que se realicen consultas adicionales para obtener la información requerida y un innecesario uso del ancho de banda del cliente, impidiendo un desempeño óptimo de la plataforma en conexiones lentas.

¿Qué es REST?

Cuando hablamos de REST nos referimos a RESTful API, una arquitectura que define los protocolos de integración entre los sistemas y un software de una aplicación. REST es el acrónimo para Representational State Transfer. En simple significa que cuando un cliente (sitio o app) envía una solicitud mediante una API REST, la respuesta es una representación del estado del objeto requerido (datos).

Esto último implica que la respuesta es stateless o sin estado; no se registra, lo que significa que cada respuesta a una llamada es única y no se recuerda en los siguientes llamados. Es el cliente quien debe ingresar la información en cada requerimiento, y donde lo común sería recibir los datos en formato JSON.

Los problemas de REST

Demos un vistazo a cada uno de los inconvenientes mencionados:

• Over-fetching; se refiere a cuando el resultado de una consulta contiene más información de la solicitada, lo que no impide satisfacer la consulta, pero implica un mayor consumo de memoria y datos al momento de ejecutarla.
• Under-fetching; es la situación opuesta, cuando la respuesta a una consulta contiene menos información de la solicitada, por ejemplo si pidiéramos los mejores libros del 2021 y obtuviéramos un listado de títulos aunque sin sus autores.

Además, para realizar consultas en REST, cada entidad o tipo de dato requiere su propio punto de entrada. Lo que a pequeña escala es bastante práctico, para grandes sitios corporativos se transforma en una compleja extensión de puntos de acceso a los datos; lo que es en parte la razón de los problemas ya mencionados.

¿Qué es GraphQL?

GraphQL es un lenguaje de consultas para las API. Proporciona un middleware que permite atender las solicitudes completas el lado del servidor. Basa su funcionamiento en esquemas de datos (data schema) los que son construidos de antemano mediante el “GraphQL Schema Definition Lenguage”, que vendría siendo la sintaxis que define tipos, campos y relaciones entre sí.

En sentido figurado, los esquemas de datos son los contratos entre clientes (app, móvil, etc.) y servidor. Definen el cómo un cliente accede a los datos, permitiendo adecuar la respuesta a los requerimientos específicos del cliente.

Sabemos que suena muy parecido a SQL y su relación con bases de datos; pero GraphQL no tiene ninguna dependencia con bases de datos, su objetivo es comunicar clientes con servidores. Además, GraphQL solo cuenta con un punto de entrada el que ejecuta todas las consultas.

Así, al estar basado en esquemas de datos no requiere un punto de entrada para cada entidad, lo que soluciona el problema que tiene REST relacionado con el Over Fetching y Under Fetching, ya que las consultas ejecutadas son respondidas acorde a los requerimientos.

Puntos en común con REST

GraphQL gana terreno respecto a REST porque también comparte puntos en común:

• Partamos por la mencionada condición de sin estado o stateless.
• Ambos comparten su condición políglota respecto al lenguaje del backend. También son altamente compatibles con diferentes framework para el frontend, lo que explica también por qué son alternativas tan populares en la arquitectura web.

Diferencias con REST

Las principales diferencias que convierten a GraphQL en una buena alternativa, sobre todo para grandes plataformas, son:

• Tal como ya se mencionó, GraphQL dispone de un único punto de entrada para realizar las consultas. A diferencia de REST que dispone de un punto de entrada para cada categoría.
• Cada consulta se ejecuta mediante el método POST, así que nos olvidamos de DELETE, GET o PUT. Las consultas son más bien una descripción de lo que se quiere obtener como respuesta.

Mayor autonomía en tus equipos y una mejor gestión de la información

Todas estas similitudes y diferencias derivan en términos operativos que a nivel interno los equipos encargados del frontend y backend trabajarán de manera autónoma entre sí, ya que ambos conocen la estructura de los datos, previamente definida en el esquema. Por otra parte, GraphQL no tiene la necesidad de ajustar las API cada vez que los requerimientos del producto o diseño cambian.

En GraphQL existen funciones que se llaman “resolvers” los que se encargan de completar los datos de un campo de tu esquema. Siempre que un cliente consulte por un campo particular, el resolver obtiene los datos solicitados de la fuente adecuada. Esto permite entregar más y mejor información del backend, lo que contribuye a mejorar el análisis de las interacciones digitales, identificando cuellos de botella o puntos bajos que impactan en las conversiones.
En Reign desde que conocimos GraphQL hemos buscado acercar esta tecnología a grandes empresas, porque permite centrarse en el desarrollo de APIs a la medida de cada empresa, agilizando el desarrollo y facilita el trabajo a la interna de los equipos.