rest - how - graphql>;

¿Hay alguna desventaja en GraphQL? (6)

Cada año es cada vez mejor y, por ahora, la community de GraphQL está creciendo y, como resultado, hay muchas más soluciones a muchos problemas que se destacaron en otras respuestas antes. Pero para admitir lo que todavía impide que las empresas arrojen todos los recursos a GraphQL, me gustaría enumerar algunos problemas y soluciones seguidos de otros sin resolver.

Caché a nivel de red : como dijo que son consultas persistentes y, por supuesto, puede almacenar en caché en un cliente y nadie lo detiene para usar el almacenamiento en caché a nivel de base de datos o incluso Redis. Pero, por supuesto, ya que GraphQL tiene solo un punto final y cada consulta es diferente: es mucho más complicado hacer este tipo de almacenamiento en caché que con REST.
Las consultas anidadas en GraphQL conducen a consultas circulares y pueden bloquear el servidor , ya no es un problema con una gran variedad de soluciones. Algunos de ellos están listados howtographql.com/advanced/4-security
Manejo de carga de archivos : ya tenemos lots solutions para ello

Pero hay un par de casos más que pueden considerarse desventajas:

exceso de repetitivo (con esto quiero decir, para crear, por ejemplo, una nueva consulta, necesita definir esquema, resolutor y dentro del resolutor para decir explícitamente a GraphQL cómo resolver sus datos y campos en el interior, en el lado del cliente cree una consulta con campos exactamente relacionados con esta información)
manejo de errores : debo decir que está más relacionado con la comparación con REST. Aquí es posible con apollo pero al mismo tiempo es mucho más complicado que en REST
autenticación y autorización , pero como dije, la comunidad está aumentando con una velocidad sobresaliente y ya hay un couple of solutions para este objetivo.

En resumen, GraphQL es solo una herramienta para objetivos específicos y, por supuesto, no es una bala de plata para todos los problemas y, por supuesto, no es un reemplazo para REST.

Todos los artículos sobre GraphQL le dirán lo maravilloso que es, pero ¿hay alguna desventaja o inconveniente? Gracias.

Creo que graphql por el momento debe ser parte de la arquitectura de back-end, para la carga de archivos todavía tienes una API normal

Desventajas

Debe aprender a configurar GraphQL. El ecosistema todavía está evolucionando rápidamente, por lo que debe mantenerse al día.
Debe enviar las consultas desde el cliente, solo puede enviar cadenas, pero si desea más comodidad y almacenamiento en caché, usará una biblioteca de cliente -> código adicional en su cliente
Debe definir el esquema de antemano => trabajo adicional antes de obtener resultados
Necesita tener un punto final graphql en su servidor => nuevas bibliotecas que aún no conoce
Las consultas Graphql son más bytes que simplemente ir a un punto final REST
El servidor necesita hacer más procesamiento para analizar la consulta y verificar los parámetros.

Pero, estos son más que contrarrestados por estos:

GraphQL no es tan difícil de aprender
El código extra es solo unos pocos KB
Al definir un esquema, evitará mucho más trabajo luego de corregir errores y soportar actualizaciones peludas
Hay muchas personas que cambian a GraphQL, por lo que se está desarrollando un ecosistema rico , con excelentes herramientas
Al usar consultas persistentes en producción (reemplazando consultas GraphQL con simplemente un ID y parámetros), en realidad envía menos bytes que con REST
El procesamiento adicional para las consultas entrantes es insignificante
Proporcionar un desacoplamiento limpio de API y backend permite una iteración mucho más rápida en mejoras de backend

Es realmente genial tener un único punto final y exponer todos los datos. A continuación encuentro los puntos a considerar para GraphQL:

La implementación de la descarga / carga de archivos se vuelve complicada (la conversión a cadena podría no ser la mejor opción para archivos grandes)
Una gran cantidad de código repetitivo y de esquema tanto en la interfaz como en el backend.
Siga y admita la paginación proporcionada en la especificación GraphQL.
Permitir orden personalizado y lógica de priorización para ordenar campos. Ejemplo si buscamos datos de usuarios y grupos y roles asociados. Un usuario puede ordenar múltiples datos según el nombre de usuario, el nombre del grupo o el nombre del rol.
La autenticación y la autorización dependerían del marco de back-end.
Asegúrese de que la optimización del backend y el soporte de la base de datos para disparar una sola consulta para cada comando graphql pueda ser complicado.

Además, uno debe considerar los Pros después de su implementación:

Muy flexible para admitir nuevos elementos y actualizar el comportamiento existente.
Condiciones fáciles de agregar utilizando argumentos y pedidos personalizados una vez implementados
Utilice muchos filtros personalizados y elimine todas las acciones que deben crearse, por ejemplo, un usuario puede tener id, nombre, etc. como argumentos y realizar el filtrado. Además, los filtros se pueden aplicar en los grupos de los usuarios también.
Facilidad de prueba API creando archivos que contienen todas las consultas y mutaciones GraphQL.
Las mutaciones son sencillas y fáciles de implementar una vez que se comprende el concepto.
Potente forma de obtener múltiples profundidades de datos.
La compatibilidad con Voyager y GraphiQL UI o Playground facilita la visualización y el uso.
Facilidad de documentación al definir el esquema con métodos de descripción válidos.

Este gran problema que veo con GraphQL es decir, si está utilizando una base de datos relacional es con combinaciones .

El hecho de que puede permitir / no permitir algunos campos hace que las uniones no sean triviales (no simples). Lo que lleva a consultas adicionales.
Además, las consultas anidadas en graphql generan consultas circulares y pueden bloquear el servidor . Se debe tener especial cuidado.
La limitación de la velocidad de las llamadas se vuelve difícil porque ahora el usuario puede disparar múltiples consultas en una sola llamada.

SUGERENCIA : utilice el cargador de datos de Facebook para reducir la cantidad de consultas en caso de javascript / nodo

He encontrado algunas preocupaciones importantes para cualquiera que esté considerando usar GraphQL , y hasta ahora los puntos principales son:

Consulta en profundidad indefinida : GraphQL no puede realizar consultas en profundidad indefinida, por lo que si tiene un árbol y desea devolver una rama sin conocer la profundidad, tendrá que hacer un poco de paginación.

Estructura de respuesta específica : en GraphQL, la respuesta coincide con la forma de la consulta, por lo que si necesita responder en una estructura muy específica, tendrá que agregar una capa de transformación para remodelar la respuesta.

Caché a nivel de red : debido a la forma común en que GraphQL se usa sobre HTTP (una POST en un único punto final), el caché a nivel de red se vuelve difícil. Una forma de resolverlo es usar consultas persistentes.

Manejo de la carga de archivos: no hay nada sobre la carga de archivos en la especificación GraphQL y las mutaciones no aceptan archivos en los argumentos. Para resolverlo, puede cargar archivos utilizando otro tipo de API (como REST) y pasar la URL del archivo cargado a la mutación GraphQL, o inyectar el archivo en el contexto de ejecución, por lo que tendrá el archivo dentro de las funciones de resolución.

Ejecución impredecible : la naturaleza de GraphQL es que puede realizar consultas combinando los campos que desee, pero esta flexibilidad no es gratuita. Hay algunas inquietudes que es bueno saber como Rendimiento y Consultas N + 1.

API súper simples : en caso de que tenga un servicio que exponga una API realmente simple, GraphQL solo agregará una complejidad adicional, por lo que una API REST simple puede ser mejor.