GraphQL vs gRPC vs REST: Elegir la API correcta puede ser una tarea difícil pero con en este tutorial la elección de la API será lo más acertada posible.
El estándar para el intercambio de datos entre frontend y backend siempre ha sido un poco polémico.
Con diferentes tecnologías API disponibles para compartir datos entre clientes y servidores, y cada una con su propio conjunto de capacidades únicas, puede ser bastante abrumador decidir cuál le sirve mejor.
Las tres tecnologías más populares actualmente para crear API son GraphQL, gRPC y REST. En esta publicación, veremos cómo funciona cada uno, incluidos sus pros y sus contras.
Tabla de contenidos
GraphQL
GraphlQL es un lenguaje de consulta de datos que permite a los clientes solicitar cualquier dato específico que necesiten. A diferencia de los métodos HTTP de REST, GraphQL utiliza consultas, mutaciones y suscripciones para obtener y manipular datos.
Las consultas solicitan datos del servidor, mientras que las mutaciones envían datos y modifican los datos controlados por el servidor. Las suscripciones obtienen actualizaciones en vivo cuando cambian los datos, generalmente a través de Websockets.
En total, GraphQL admite lenguajes como JavaScript, Java, Python, Ruby, PHP y más.
Representación de datos con esquemas
Con GraphQL, los datos se representan a través de esquemas. Un esquema define un objeto, los campos que contiene el objeto y el tipo de datos que pueden contener los campos.
Aquí hay un esquema de ejemplo:
type User {
name: String!
age: Number!
}
Aquí, User es el objeto, y dentro de él, especificamos los campos o propiedades que tiene el objeto, incluidos los tipos de datos.
Lo que esto significa es que en cualquier consulta que opere sobre el objeto User, los únicos campos que pueden aparecer son name y age. Para ambos campos, los únicos tipos de datos que se pueden escribir o leer son cadenas y números, respectivamente.
En GraphQL, cuando los tipos de campo van seguidos de signos de exclamación como los que tenemos arriba, significa que los campos no aceptan valores NULL. Deben tener datos escritos en ellos cuando el objeto se actualiza y los campos siempre proporcionan valores cuando se consultan.
Definición de consultas, mutaciones y suscripciones con esquemas
Como se mencionó anteriormente, existen principalmente tres acciones que se pueden realizar en los objetos de datos: consultas (queries), mutaciones (mutations) y suscripciones (subscriptions). Estos también se pueden definir usando el lenguaje de esquema de GraphQL.
Con un esquema de query, puede solicitar datos de su servidor GraphQL especificando el objeto y los campos debajo del objeto que le interesa:
query {
users {
name
age
}
}
Arriba, solicitamos una lista de los usuarios en la base de datos, específicamente sus nombres y edades. El objeto user podría tener otros campos como gender o job, por ejemplo, pero solo se nos enviarán los campos que solicitamos.
Esta es una ventaja que GraphQL tiene sobre REST. En REST, cuando se consulta un punto final, se le envían todos los datos detrás de ese punto final, lo que le permite ordenar el array y seleccionar los campos particulares que necesita.
GraphQL es más flexible porque le permite personalizar la estructura de su resultado. Esto ahorra en el consumo de memoria y CPU que se dedica al filtrado de datos. Debido a que las consultas GraphQL generalmente solicitan menos datos, generalmente se procesan más rápido que las solicitudes REST.
Con un esquema de mutation, puede realizar cambios en los datos existentes o publicar nuevos datos en su base de datos. Por ejemplo, si quisiera crear un nuevo usuario o actualizar los detalles de un usuario existente, usaría la mutación:
mutation {
newUser($name: name!, $age: age!) {
name
age
}
}
Con un esquema subscription, puede suscribirse a un objeto y hacer que su servidor actualice su cliente en tiempo real cada vez que se realicen cambios en ese objeto.
Por ejemplo, si desea que la aplicación de su cliente se actualice en tiempo real cada vez que se elimine o modifique un usuario existente, o se cree un nuevo usuario, puede suscribirse al objeto User y sus campos de interés:
subscription User {
newUser {
name
age
}
}
Ventajas de GraphQL
Con GraphQL, puede definir el alcance exacto de los datos requeridos en cada petición. Al evitar que el exceso de datos se envíe desde el servidor al cliente, su aplicación funciona mejor.
Dado que puede seleccionar varios campos de diferentes recursos en una sola consulta, GraphQL elimina la necesidad de realizar múltiples viajes de ida y vuelta al servidor para obtener datos para su cliente.
Contras de GraphQL
GraphQL tiene, actualmente, algunos problemas de almacenamiento en caché (específicamente el almacenamiento en caché HTTP) que han contribuido a retrasar su adopción generalizada.
Debido a la forma en que se escriben las consultas de GraphQL, solicitar demasiados campos anidados a la vez puede generar consultas circulares y bloquear su servidor. La implementación de la limitación de velocidad en REST es más fluida.
GraphQL tampoco admite la subida de archivos y requiere una solución alternativa para implementar esta funcionalidad.
Finalmente, en comparación con REST, GraphQL tiene una curva de aprendizaje más pronunciada.
REST
El formato de API más popular y más utilizado de la lista es REST, que significa transferencia de estado representacional.
Las API REST usan métodos HTTP como GET, POST, PUT y DELETE` para acceder y manipular datos dentro de identificadores uniformes de recursos (URI):
- GET para recuperar datos de un servidor
- POST para transferir datos del cliente al servidor
- PUT para modificar los datos en el servidor
- DELETE para eliminar datos en el servidor
Cuando está en uso, por ejemplo, una solicitud GET puede realizarse en un URI, que normalmente se parece a /api/users, una operación REST normalmente devuelve datos del servidor al cliente.
Los datos de respuesta REST pueden venir en formatos como JSON, CSV, XML o RSS, y los datos de respuesta REST tienden a venir en pares de propiedad/valor:
{
"users": {
{
"id": "1",
"name": "Jose",
"age": "35"
},
{
"id": "2",
"name": "Lucia",
"age": "19"
}
}
}
Ventajas de REST
El almacenamiento en caché es fácil en REST porque aprovecha HTTP al eliminar la necesidad de que su cliente y servidor interactúen constantemente entre sí, mejorando el rendimiento y la escalabilidad.
La madurez de REST en el mundo tecnológico es una de sus mayores ventajas. Es omnipresente, a diferencia de GraphQL y gRPC, que pueden considerarse soluciones de nicho para crear API.
Debido a la popularidad de REST, muchos desarrolladores ya están familiarizados con él y les resulta fácil trabajar con él. Por tanto, seguramente sea la mejor opción si se desea crear una API comercial para que la consuman muchos desarrolladores externos.
Contras de REST
Grandes payloads: mientras que en GraphQL puede seleccionar campos específicos de un recurso, en REST requiere que solicite todos los datos del recurso antes de recorrerlo para obtener los datos que necesita, lo que a menudo resulta en grandes payloads.
Mientras que con GraphQL podemos procesar por lotes diferentes solicitudes de recursos y enviarlas al mismo punto final en /graphql, y ejecutarlas una vez en un viaje de ida y vuelta, con REST, se deben enviar diferentes solicitudes a diferentes puntos finales, lo que da como resultado múltiples viajes de ida y vuelta.
GraphQL hace que realizar cambios en el esquema de una base de datos sea muy fácil. Dado que las consultas solo implican la solicitud de campos específicos, se pueden eliminar nuevos campos de un recurso sin provocar cambios importantes ni requerir que modifique la versión de su aplicación.
gRPC también viene con sus propias características de compatibilidad con versiones anteriores que facilitan la actualización de su estructura de datos sin romper el código de los clientes. REST no viene con esta flexibilidad.
gRPC
gRPC es, a grandes ragos, un marco de llamada de procedimiento remoto (RPC) de código abierto y alto rendimiento creado por Google.
En gRPC, los buffers de protocolo realizan solicitudes de API al servidor. Estas solicitudes y respuestas de API son mensajes de buffer de protocolo, y cada uno debe tener su propio tipo definido utilizando el lenguaje de buffers de protocolo.
Los servicios se definen para emparejar solicitudes de API con sus respuestas correspondientes, y el compilador de buffers de protocolo genera los artefactos de código de servidor y cliente para su servicio de API:
// Syntax version
syntax = "proto3";
service UserService {
rpc GetUser (UserRequest) returns (UserResponse);
}
// Message type
message UserResponse {
string name = 1;
string age = 2;
}
message UserRequest {
string name = 1;
string age = 2;
}
En este bloque de código, el mensaje UserRequest es la solicitud, el mensaje UserResponse es la respuesta y GetUser es el extremo de la API.
gRPC es compatible con una gran cantidad de lenguajes de programación y su aplicación de cliente se puede escribir en cualquiera de estos idiomas porque el código de cliente para cualquiera de estos idiomas se puede generar con la ayuda de la herramienta protoc.
Ventajas de gRPC
Los buffers de protocolo, con los que gRPC viene listo para usar, admiten más tipos de datos que JSON y son significativamente más rápidos, gracias a su formato binario optimizado.
gRPC es compatible con la transmisión full-duplex desde el primer momento, lo que lo hace adecuado para funciones como vídeo y llamadas de voz. Con REST, por otro lado, las consultas se manejan una a la vez.
gRPC realiza el balanceo de carga para que las solicitudes de los clientes se distribuyan uniformemente entre los servidores para evitar la sobrecarga de un servidor en particular. Esto mejora el rendimiento general de las aplicaciones.
La función de balanceo de carga, así como el hecho de que gRPC usa HTTP2 de manera predeterminada, hace que la latencia en gRPC sea mucho más baja que en las API REST.
Finalmente, gRPC serializa datos en formato binario (protocol buffers), que es mucho más rápido que JSON de REST, lo que le da a gRPC una mayor ventaja de rendimiento.
Contras de gRPC
Los protocol buffers, el formato de datos oficial de gRPC, actualmente solo admite un puñado de lenguajes de programación. No es compatible con lenguajes de programación populares como R o Swift.
gRPC no viene con soporte de navegador listo para usar, aunque existen algunas soluciones para ello.
Conclusión
Como en esta vida todo depende, este caso no va a ser la excepción y es que la mejor tecnología de API para un proyecto específico dependerá de lo que se intente lograr con dicho proyecto.:
- Si necesita una API genérica que usarán muchos clientes, REST podría ser su mejor opción.
- Si necesita una API flexible que usarán diferentes clientes para realizar muchas solicitudes únicas, entonces podría ser mejor dejar que los clientes creen sus propias consultas únicas y obtengan solo los datos específicos que necesitan rápidamente, y puede lograr esto con GraphQL.
- Si desea crear una comunicación rápida y fluida entre los servicios internos, gRPC es su mejor opción.
Como hemos visto, los tres tienen sus pros y sus contras y puedes obtener resultados óptimos combinando tecnologías.
Espero que el artículo «GraphQL vs gRPC vs REST: Elegir la API correcta» te haya sido de ayuda ❤️