¿Hay alguna desventaja de GraphQL? [cerrado]

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

Desventajas:

• Usted necesita aprender cómo 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 tienen 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, esos son más que contrarrestados por estos:

• GraphQL no es tan difícil de aprender
• El código adicional es solo unos pocos KB
• Al definir un esquema, evitará mucho más trabajo después de corregir errores y soportar actualizaciones complicadas
• Hay mucha gente que se cambia a GraphQL, por lo que se está desarrollando un rico ecosistema , con excelentes herramientas
• Cuando usa consultas persistentes en producción (reemplazando las consultas GraphQL con simplemente una 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 las mejoras del backend

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 una 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 a través de HTTP (un POST en un solo punto final), el caché a nivel de red se vuelve difícil. Una forma de resolverlo es utilizar 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 usando 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 preocupaciones que conviene conocer, como el rendimiento y las 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.

El mayor problema que veo con graphQL, es decir, si está utilizando una base de datos relacional, es con uniones .

1. El hecho de que pueda permitir / no permitir algunos campos hace que las uniones no sean triviales (no simples). Lo que conduce a consultas adicionales.

2. Además, las consultas anidadas en graphql conducen a consultas circulares y pueden bloquear el servidor . Se debe tener especial cuidado.

3. La limitación de la velocidad de las llamadas se vuelve difícil porque ahora el usuario puede realizar múltiples consultas en una llamada.

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

Es cada vez mejor y mejor cada año y, por ahora, la comunidad de GraphQL está creciendo y, como resultado, hay muchas más soluciones para 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 Bruno , se trata de consultas persistentes y, por supuesto, puede almacenar en caché en un cliente y nadie le impide usar el almacenamiento en caché en el nivel de base de datos o incluso Redis. Pero, por supuesto, como 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 generan consultas circulares y pueden bloquear el servidor , lo que ya no es un problema con una amplia variedad de soluciones. Algunos de ellos se enumeran aquí
• Manejo de Carga de archivo - hemos ya un montón de soluciones para ello

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

• excesividad repetitiva (con esto quiero decir, para la creación, por ejemplo, de una nueva consulta, debe definir el esquema, el resolutor y dentro del resolutor para decir explícitamente GraphQL cómo resolver sus datos y campos en el interior, en el lado del cliente cree una consulta con exactamente campos relacionados con estos datos)
• Manejo de errores : debo decir que está más relacionado con la comparación con REST. Es posible aquí con apollo pero al mismo tiempo es mucho más complicado que en REST
• autenticación y autorización - pero como dije comunidad está aumentando a una velocidad excepcional y hay ya par de soluciones para este objetivo.

En resumen, GraphQL es solo una herramienta para objetivos específicos y seguro que no es una solución mágica para todos los problemas y, por supuesto, no reemplaza a REST.

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

1. La implementación de la descarga / carga de archivos se vuelve complicada (la conversión a cadena puede no ser la mejor opción para archivos grandes)
2. Una gran cantidad de código estándar y de esquema tanto en el frontend como en el backend.
3. Siga y admita la paginación proporcionada en la especificación GraphQL.
4. Permitir el orden personalizado y la lógica de priorización para ordenar los campos. Ejemplo si obtenemos datos de usuarios y grupos y roles asociados. Un usuario puede ordenar los datos de forma múltiple según el nombre de usuario, el nombre del grupo o el nombre del rol.
5. La autenticación y la autorización dependerían del marco de backend.
6. Asegúrese de que la optimización del backend y el soporte de la base de datos para lanzar una sola consulta para cada comando graphql puedan ser complicados.

Además, se deben considerar los Pros después de su implementación:

1. Muy flexible para admitir nuevos elementos y actualizar el comportamiento existente.

2. Fácil de agregar condiciones usando argumentos y orden personalizado una vez implementado

3. Use 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 también se pueden aplicar a los grupos de los usuarios.

4. API de prueba fácil mediante la creación de archivos que contienen todas las consultas y mutaciones de GraphQL.
5. Las mutaciones son sencillas y fáciles de implementar una vez que se entiende el concepto.
6. Una forma poderosa de obtener múltiples profundidades de datos.
7. La compatibilidad con la interfaz de usuario o el patio de juegos de Voyager y GraphiQL hace que sea fácil de ver y usar.
8. Facilidad de documentación al definir el esquema con métodos de descripción válidos.

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