¿Es el futuro de la comunicación servidor-cliente gRPC o GraphQL?

Descargo de responsabilidad: uso GraphQL en producción pero no he usado gRPC. Solo he hojeado los documentos y tengo una comprensión teórica de RPC en general.

gRPC y GraphQL resuelven un problema ligeramente diferente y, por lo tanto, sus casos de uso variarán.

gRPC es un sistema estándar RPC (llamada a procedimiento remoto), cuyo concepto realmente no ha cambiado mucho desde que se utilizó por primera vez en la década de 1960. Como su nombre indica, se utiliza para ejecutar funciones en alguna máquina remota.

GraphQL, por otro lado, se centra principalmente en la obtención de datos. Su poder proviene de poder definir una estructura de datos compleja que se necesita para representar una vista particular (puede leer más en mi publicación mediana [1]), y le permite al cliente desacoplar vistas de puntos finales de servidores individuales.

Creo que GraphQL es más adecuado para crear productos para usuarios finales, ya que optimiza la comunicación cliente-servidor para obtener datos para una página. Como los clientes suelen ser móviles, el énfasis está en disminuir la cantidad de llamadas remotas (idealmente, buscar todos los datos en una sola solicitud).

gRPC se usa ampliamente en un entorno servidor-servidor distribuido donde un sistema necesita invocar una función que está expuesta por otro sistema. El énfasis aquí está en lograr una sobrecarga mínima para llamadas individuales, y los datos se transfieren muy a menudo en binario.

Como siempre, ninguna solución individual es 100% perfecta para cualquier caso de uso. Si está creando una aplicación móvil / web con un solo servidor (o una fachada con varios servidores), es probable que GraphQL sea una buena opción. Si, por otro lado, tiene una arquitectura orientada al servicio, puede usar gRPC para facilitar la comunicación entre los servidores.

Notas al pie

[1] GraphQL en la era de las API REST – Chute Engineering

Ambos son útiles si desea que la interfaz del lado del cliente permanezca igual mientras cambia el lado del servidor. Esto tiene un gran uso para estandarizar la comunicación del lado del cliente mientras se cambia la implementación del backend. Esto ciertamente tiene usos en algunos casos, pero no es la única forma. Por ejemplo, GraphQL es demasiado en un solo escenario de base de datos, ya que debe configurar el lado del cliente y el servidor GraphQL.

Creamos Hasura BaaS para aprovechar GraphQL como interfaz (relaciones anidadas, etc.) aunque en una interfaz JSON más simple en un Postgres Db. Creo que este puede ser el futuro 🙂

Leer más: API de datos en Postgres #HasuraBaaS