GraphQL vs REST API ¿Cuál debes usar para tu backend?

Posted by Por M.Domínguez 13 Minutos de lectura
GraphQL vs REST API PORTADA

En este artículo viviremos una batalla épica, GraphQL vs REST API. Ambas son formas estándar de desarrollar APIs de backend. Pero en la última década las APIs REST han dominado como opción para desarrollar APIs backend. Y muchas empresas y desarrolladores la utilizan activamente en sus proyectos.

Pero REST tiene algunas limitaciones, y hay otra alternativa disponible – GraphQL. GraphQL es una gran opción para desarrollar APIs en grandes bases de código.

¿Por qué GraphQL vs REST API?

Lo primero que vamos a tener en cuenta en este GraphQL vs REST API será todo lo que hasta ahora sabíamos en cuestión de consumos de API y generación en backend. Luego, además de cumplir con el procedimiento analítico de ambas mostraremos si ya están anitcuados o se pueden seguir utlizando aún teniendo en cuenta todos los puntos que mostraremos.

¿Qué es GraphQL?

GraphQL fue desarrollado por Facebook en 2012 para uso interno y se hizo público en 2015. Es un lenguaje de consulta para APIs y un tiempo de ejecución para cumplir esas consultas con sus datos existentes. Muchas empresas lo utilizan en producción.

El sitio web oficial presenta GraphQL así:

GraphQL proporciona una descripción completa y comprensible de los datos de tu API, da a los clientes el poder de pedir exactamente lo que necesitan y nada más, facilita la evolución de las APIs a lo largo del tiempo y permite potentes herramientas para desarrolladores.
Y en este blog veremos cómo funciona todo esto.

Problemas con las APIs REST

  • Consulta de múltiples puntos finales
  • OverFetching
  • UnderFetching y el problema de n+1 solicitudes
  • No es súper rápido para hacer frente a los requisitos cambiantes del cliente final
  • Alto acoplamiento entre los controladores del backend y las vistas del frontend

Entonces, ¿cuáles son estos problemas y cómo los resuelve GraphQL? Bueno, aprenderemos más adelante. Pero primero tendremos que asegurarnos de que te sientes cómodo con los conceptos básicos de GraphQL como el sistema de tipos, el esquema, las consultas, las mutaciones, etc.

Ahora veremos algunos ejemplos para entender mejor las desventajas de usar las APIs REST.

Sobrecarga o Overfetching

Supongamos que necesitamos mostrar esta tarjeta de usuario en la interfaz de usuario.

GraphQL vs REST API captura 1

Con REST, la petición va a ser un GET a /users/1.

El problema aquí es que el servidor devuelve una estructura de datos fija, algo así:

{
    "_id": "1",
    "name": "Aagam Vadecha",
    "username": "aagam",
    "email": "testemail@gmail.com",
    "currentJobTitle": "Software Engineer",
    "phone": "9876543210",
    "intro": "Como ingeniero de software, mi rutina diaria gira en torno a la escritura de código limpio, el mantenimiento de la infraestructura y la creación de sistemas de software escalables. En mi tiempo libre me gusta escribir blogs de tecnología, trabajar como freelance, escuchar música y ver películas de suspense.",
    "website": "https://www.aagam.tech",
    "gender": "MALE",
    "city": "Surat",
    "state": "Gujarat",
    "country": "India",
    "display_picture": "8ba58af0-1212-4938-8b4a-t3m9c4371952",
    "phone_verified": true,
    "email_verified": true,
    "_created_at": "2021-03-08T14:13:41Z",
    "_updated_at": "2021-03-08T14:13:41Z",
    "_deleted": false
}

El servidor devuelve datos adicionales (aparte del nombre, la introducción y la designación del trabajo) que no son necesarios en el extremo del cliente para construir la tarjeta en este punto, pero la respuesta todavía los tiene. Esto se llama overfetching.

El overfetching aporta datos extra en cada petición que no son necesarios para el cliente. Y esto aumenta el tamaño de la carga útil y, finalmente, esto tiene un efecto en el tiempo de respuesta global de la consulta.

Y lo que es peor, la situación se agrava cuando una consulta trae datos de múltiples tablas aunque el cliente no los requiera en ese momento. Así que si podemos evitarlo, definitivamente deberíamos

Con GraphQL, la consulta dentro del cuerpo de la petición se vería algo así:

GraphQL vs REST API captura 2

Sólo devolverá el nombre, la introducción y el currentJobTitle según lo requerido por el cliente, por lo que el problema de overfetching está resuelto.

La búsqueda insuficiente o underfetching y el problema de n+1 peticiones

Ahora supongamos que esta UserList necesita ser mostrada en la UI.

GraphQL vs REST API captura 3

Con REST, considerando que «experience» es una tabla que tiene una clave externa de user_id, hay tres opciones posibles y es algo que encauza este GraphQL vs REST API, veámoslo:

  1. Una de ellas es enviar una estructura de datos exacta y fija de todas las tablas vinculadas con claves extranjeras a la tabla de usuarios en la petición GET /users, y muchos frameworks proporcionan esta opción.
{
    "_id": "1",
    "name": "Aagam Vadecha",
    "username": "aagam",
    "email": "testemail@gmail.com",
    "currentJobTitle": "Software Engineer",
    "phone": "9876543210",
    "intro": "Como ingeniero de software, mi rutina diaria gira en torno a la escritura de código limpio, el mantenimiento de la infraestructura y la creación de sistemas de software escalables. En mi tiempo libre me gusta escribir blogs de tecnología, trabajar como freelance, escuchar música y ver películas de suspense.",
    "website": "https://www.aagam.tech",
    "gender": "MALE",
    "city": "Surat",
    "state": "Gujarat",
    "country": "India",
    "display_picture": "8ba58af0-1212-4938-8b4a-t3m9c4371952",
    "phone_verified": true,
    "email_verified": true,
    "_created_at": "2021-03-08T14:13:41Z",
    "_updated_at": "2021-03-08T14:13:41Z",
    "_deleted": false,
    "experience": [
        {
            "organizationName": "Bharat Tech Labs",
            "jobTitle": "Software Engineer",
            "totalDuration": "1 Year"
        }
    ],
    "address": [
        {
            "street": "Kulas Light",
            "suite": "Apt. 556",
            "city": "Gwenborough",
            "zipcode": "929983874",
            "geo": {
                "lat": "-37,3159",
                "lng": "81.1496"
            }
        }
    ]
}

Pero este método hace consultas costosas, sobrecarga todas las otras peticiones /users también, y termina trayendo un montón de datos de todas las tablas extranjeras (dirección, experiencia) que no es necesario en la mayoría de los casos. Esta es una de las razones de peso por el cual nos decidimos a hacer esta guía GraphQL vs REST API, ya que muchos desarolladores aún no se dan cuenta de que, en los tiempos actuales, tanto aplicaciones móviles, como web, mueven un número increíble de peticiones y cada vez son más. Esto hace que dentro de un par de años, crear una aplicación con la misma arquitectura de hoy en día se hará practicamente imposible.

Por ejemplo, quieres los datos del usuario en algún otro lugar del frontend donde sólo necesitas mostrar el sitio web del usuario, así que haces una petición GET user/1. Pero esto sobreobtiene datos de la tabla de experiencia así como de la tabla de direcciones, que no necesitas en absoluto.

2. La segunda opción es que el cliente puede hacer múltiples viajes al servidor así:

GET /users 
GET users/1/experience

Este es un ejemplo de underfetching, ya que un punto final no tiene suficientes datos. Pero las múltiples llamadas a la red ralentizan el proceso y afectan a la experiencia del usuario 🙁

Además, en este caso concreto de una Lista, el underfetching se intensifica y nos encontramos con el problema de n+1 peticiones.

Es necesario hacer una llamada a la API para obtener todos los usuarios y luego llamadas individuales a la API para cada usuario para obtener su experiencia, algo así:

GET /users 
GET /users/1/experience 
GET /users/2/experience 
...
GET /users/n/experience.

Esto se conoce como el problema de las n+1 peticiones. Para resolver este problema, lo que generalmente se hace es la tercera opción, que discutiremos ahora.

3. Otra opción es hacer un controlador personalizado en el servidor que devuelva la estructura de datos que cumpla con los requisitos del cliente en ese momento.

GET /user-experience

Esto es lo que se hace en los principales casos de API REST del mundo real.

Por otro lado, una simple petición GraphQL que funcionaría sin problemas y sin necesidad de desarrollo en el servidor, sería algo así:

GraphQL vs REST API captura 4

Sin overfetching, sin underfetching, y sin desarrollo en el servidor. Simplemente fantástico, ¿empiezas a ver hacía donde cae la balanza en este GraphQL vs REST API?

Acoplamiento estrecho entre las vistas del frontend y las API del backend

Llegados a este punto del GraphQL vs REST API seguramente ya tienes unas cuantas razones de peso para, por lo menos, comenzar a leerte la información de algún tutorial sobre el tema. Bien, de acuerdo, podrías argumentar que puedes usar REST, hacer el controlador del servidor con un único esfuerzo de desarrollo inicial, y ser feliz – ¿cierto?

Pero hay un inconveniente importante que viene junto con el uso de controladores personalizados.

Hemos formado un acoplamiento estrecho con la vista del frontend y el controlador del backend, por lo que en general necesita más esfuerzo para hacer frente a los cambios en el extremo del cliente. También nos da menos flexibilidad.

Como ingenieros de software, sabemos que los requisitos cambian a menudo. El controlador personalizado en este punto GET /user-experience está devolviendo datos dependiendo de lo que la vista del frontend quiere mostrar (nombre del usuario y rol actual). Así que cuando un requisito cambia, tenemos que refactorizar tanto el cliente como el servidor.

Por ejemplo, después de un tiempo considerable, los requisitos cambian y en lugar de los datos de la experiencia la UI necesita mostrar la información de la última transacción del usuario.

GraphQL vs REST API captura 5

Con Rest, tendríamos que hacer los cambios pertinentes en la capa del frontend. Además, para devolver los datos de la transacción en lugar de los datos de la experiencia desde el backend, el controlador personalizado tendrá que ser refactorizado (datos enviados, ruta, etc) o tendremos que hacer un nuevo controlador en caso de que queramos conservar el antiguo.

Así que, básicamente, un cambio en los requisitos del cliente influye en gran medida en lo que debe devolver el servidor – ¡lo que significa que tenemos un estrecho acoplamiento entre el frontend y el backend!

Sería mejor no tener que hacer ningún cambio en el servidor, sino sólo en el frontend.

Con GraphQL no necesitaremos hacer ningún cambio en el lado del servidor. El cambio en la consulta del frontend sería tan mínimo como esto:

GraphQL vs REST API captura 6

No hay que refactorizar la API del servidor, ni desplegarla, ni probarla – ¡esto significa tiempo y esfuerzo ahorrados!

Conclusión

Como espero que puedas ver en este artículo del GraphQL vs REST API, GraphQL tiene una serie de ventajas sobre REST en muchas áreas.

Puede tomar más tiempo para configurar GraphQL inicialmente, pero hay muchos caminos que hacen ese trabajo más fácil. E incluso si lleva más tiempo al principio, te da ventajas a largo plazo y vale totalmente la pena.

Ahora bien, como en todas las guías y artículos basados en nuestras experiencias y opiniones, solo tenemos que decirte que al final, la mejor opción es con la que mejor desarrolles, eso sí, nunca tengas miedo de salir de tu zona de confort, ya que así es como se avanza en este mundillo de la programación.

Si quieres saber más cosas sobre GraphQL puedes visitar nuestro artículo sobre las 5 razones por las que los desarrolladores Frontend adoran GraphQL

Tags: