El papel y el impacto de GraphQL

GraphQL ha surgido como un enfoque moderno y eficiente para el desarrollo de API, superando las limitaciones de las API REST tradicionales. Si bien REST se ha utilizado ampliamente desde los primeros días de la web, GraphQL ofrece una perspectiva nueva y un mayor control para los desarrolladores. Con GraphQL, los desarrolladores pueden definir un esquema fuertemente tipado que permite a los clientes solicitar con precisión los datos que necesitan. Al eliminar la obtención excesiva o insuficiente de datos, GraphQL optimiza el rendimiento y facilita la creación de aplicações web modernas e interactivas que tienen requisitos complejos de consulta y modelado de datos.

Sin embargo, reconocemos que GraphQL no está exento de desafíos. Este documento proporciona información sobre las preocupaciones de seguridad y la curva de aprendizaje asociada con la adopción de GraphQL. Exploramos estudios de casos del mundo real que describen los beneficios obtenidos por empresas reconocidas que han implementado GraphQL con éxito.

Además, presentamos nuestra propia investigación sobre GraphQL, compartiendo nuestras experiencias y descubrimientos. Describimos una breve introducción a GraphQL, lo comparamos con REST y profundizamos en los desafíos que aborda. También se analizan consideraciones de seguridad para ayudar a las organizaciones a tomar decisiones informadas. Nuestra investigación revela el potencial transformador de GraphQL. Mostramos cómo simplificamos la arquitectura de un software de gestión de pruebas, lo que resultó en un crecimiento de más del 300% en la cantidad de datos expuestos ocultos dentro de objetos JSON a través de GraphQL.

En conclusión, recomendamos encarecidamente que las empresas que luchan por escalar, optimizar u operar una infraestructura de API REST consideren GraphQL como una solución viable. Nuestros conocimientos ofrecen orientación práctica a quienes se embarcan en el viaje GraphQL, permitiéndoles aprovechar sus beneficios y superar los desafíos de manera efectiva.

Las limitaciones de las API REST están impulsando la demanda de un nuevo enfoque tecnológico de API.

El enfoque basado en REST (Transferencia de Estado Representacional) se propuso originalmente como un conjunto de principios arquitectónicos para diseñar API web. REST evolucionó a lo largo de la década de 2000 y 2010 con el surgimiento de la Web 2.0 como un mejor medio para implementar la arquitectura orientada a servicios (SOA) sobre otras tecnologías como Common Object Request Broker Architecture (CORBA).

A medida que el número de clientes creció debido a la adopción de dispositivos móviles, aumentó la demanda de datos precisos. Sin embargo, las API basadas en REST a menudo dieron lugar a una obtención excesiva o insuficiente de datos, lo que generó ineficiencias. Este enfoque, ejemplificado por aplicaciones como Facebook, a menudo requería numerosas llamadas a la API REST para una sola actualización, lo que aumentaba el tráfico de la red y comprometía el rendimiento y la experiencia del usuario.

GraphQL fue diseñado específicamente para abordar estas limitaciones al ofrecer un esquema fuertemente tipado y una forma más eficiente de consultar datos. Esto lo hace ideal para casos de uso donde se requieren datos específicos para optimizar el ancho de banda de la red. Además, la capacidad de GraphQL para introspeccionar el esquema permite una mejor documentación y herramientas. Si bien una implementación más estandarizada de REST podría haber proporcionado cierta competencia, las características y beneficios únicos de GraphQL lo convierten en una opción atractiva para las arquitecturas de aplicação modernas que son distribuidas y hacen un uso intensivo de datos.

La figura 1 muestra una diferencia topológica entre cómo se implementan REST y GraphQL. Como se indica en REST API vs GraphQL , “la diferencia clave entre GraphQL y las API REST es que GraphQL es un lenguaje de consulta, mientras que REST es un concepto arquitectónico para software basado en red”. 

Meta creó GraphQL en 2012 ( de código abierto en 2015) para mejorar el rendimiento y la flexibilidad de sus aplicaciones móviles. Antes de GraphQL, las aplicaciones móviles de Meta se creaban utilizando una combinación de API RESTful y código nativo, lo que dificultaba el manejo de la amplia gama de dispositivos, tamaños de pantalla y condiciones de red que las aplicaciones necesitaban soportar. 

Uno de los principales desafíos que enfrentaron fue que las API RESTful a menudo devolvían una cantidad incorrecta de datos: a veces demasiados y a veces muy pocos. Cuando la API devolvió una gran cantidad de datos que las aplicaciones móviles no necesitaban, esto generó tiempos de carga lentos y un rendimiento deficiente. Cuando la API devolvía muy pocos datos, las aplicaciones móviles necesitaban realizar múltiples solicitudes a diferentes puntos finales para obtener todos los datos que necesitaban, lo que agregaba latencia y complejidad al proceso.

Meta desarrolló GraphQL para que cualquier aplicación pudiera solicitar solo los datos que necesitaba en una sola solicitud. Esto permitió optimizar la transferencia de datos entre las aplicaciones móviles y los servicios backend, lo que generó tiempos de carga más rápidos y un mejor rendimiento. Además, las fuertes características de tipado y autodocumentación de GraphQL hicieron que fuera más fácil para los desarrolladores comprender y consumir la API. 

GraphQL ofrece potentes capacidades para la recuperación y manipulación de datos, lo que proporciona beneficios significativos sobre los enfoques API tradicionales. 

GraphQL cuenta con un esquema fuertemente tipado que garantiza claridad y precisión al definir la estructura y los tipos de datos que se pueden consultar desde una API. Supongamos que tenemos una API para una biblioteca que contiene libros, autores y editoriales. 

a) Esquema GraphQL : En GraphQL, un esquema fuertemente tipado se vería como la Figura 2 a continuación: 

Los esquemas fuertemente tipados en GraphQL ofrecen beneficios relacionados con la seguridad al permitir la validación de entrada, evitar la obtención excesiva o insuficiente de datos, brindar un soporte claro de documentación y herramientas, facilitar el control de versiones y ayudar en la autorización y el control de acceso. Estas características mejoran la seguridad de la API al reducir el riesgo de vulnerabilidades comunes y garantizar el manejo adecuado de los datos y la gestión de acceso.

En el ejemplo mostrado (Figura 2), el esquema define los tipos de datos para libros, autores y editores, y sus relaciones entre sí. El esquema está fuertemente tipado , lo que significa que cada campo tiene un tipo de dato específico y los clientes pueden introspeccionar fácilmente el esquema para descubrir los campos disponibles y sus tipos.

b) Esquema REST : En REST, la definición del esquema se tipificaría de forma flexible como se muestra en la Figura 3 a continuación: 

Estos puntos finales devuelven objetos JSON que representan los libros, autores y editores, pero el esquema en sí no está definido explícitamente y queda a la habilidad e interpretación del programador. Los clientes tendrán que confiar en la documentación para comprender la estructura de los datos.

GraphQL ha evolucionado más allá de ser una mejor alternativa a REST y tiene el potencial de ser un enfoque preferido para las empresas que consideran una mejor estrategia de datos. Además de resolver las limitaciones de REST, existen otras razones por las que GraphQL ha evolucionado hacia un nuevo enfoque para el diseño de API. Si bien la tabla (Figura 4) puede mostrar ventajas de GraphQL sobre REST, es mejor pensar en GraphQL como una respuesta a la evolución de Internet y diferentes aplicações en lugar de una respuesta a la identificación de problemas con REST en sí.

Si bien GraphQL ofrece muchas ventajas sobre las API RESTful tradicionales, su uso también presenta algunos desafíos. Los desafíos más comunes incluyen:

1. Curva de aprendizaje: Debido a que la mayoría de los desarrolladores están más familiarizados con REST, las organizaciones que planean adoptar GraphQL necesitarán reservar tiempo para que sus equipos aprendan a usarlo de manera efectiva. GraphQL requiere una forma diferente de pensar acerca de la creación y el consumo de API y su adopción podría requerir cambios en la arquitectura de la aplicação subyacente. Es posible que los desarrolladores necesiten aprender nuevos conceptos, como esquemas, solucionadores y tipos, así como nuevas herramientas y bibliotecas. Con GraphQL, los clientes tienen más control sobre los datos a los que pueden acceder, lo que puede dificultar la protección de las API. Es posible que sea necesario aplicar técnicas como validación de entrada, autenticación y autorización de forma diferente que con las API RESTful.
2. Almacenamiento en caché : El almacenamiento en caché puede ser más complejo con GraphQL, ya que los clientes pueden solicitar datos diferentes con cada consulta, lo que dificulta el almacenamiento en caché y la reutilización de las respuestas.
3. Actuación : Si bien GraphQL permite a los clientes solicitar solo los datos que necesitan, también puede permitir consultas más complejas y que requieren muchos recursos. Las API de GraphQL pueden tener problemas de rendimiento, especialmente cuando se consultan conjuntos de datos grandes o cuando se realizan una gran cantidad de solicitudes simultáneas. Los desarrolladores necesitan implementar estrategias como limitar la profundidad de la consulta o garantizar que los clientes estén autorizados a acceder solo a los datos específicos que necesitan.
4. Manejo de errores : GraphQL puede hacer que el manejo de errores sea más complejo, ya que los errores pueden devolverse como parte de la respuesta en lugar de como un código de estado HTTP separado.
5. Prueba : Las pruebas con GraphQL presentan desafíos debido a la complejidad de las consultas, la falta de enfoques de pruebas estandarizados, la evolución del esquema y la validación de consultas durante el tiempo de ejecución. Los desarrolladores necesitan invertir tiempo en encontrar marcos y herramientas de prueba adecuados para abordar estos desafíos. Los desarrolladores deben garantizar una cobertura de pruebas integral seleccionando las herramientas adecuadas y considerando la evolución del esquema para probar eficazmente las API GraphQL y garantizar su funcionalidad y estabilidad.
6. Monitoreo : Monitorear las API de GraphQL puede ser un desafío debido a la complejidad de las consultas, la falta de registros y métricas estandarizados y la posibilidad de que surjan problemas de rendimiento. La naturaleza dinámica de las consultas GraphQL hace que sea más difícil predecir y monitorear la estructura y el tamaño de los datos solicitados. La ausencia de herramientas de monitoreo estandarizadas específicas para las API de GraphQL dificulta la obtención de información sobre el rendimiento de las consultas de GraphQL, el seguimiento de errores y el estado de la API. Los desarrolladores necesitan adoptar herramientas y prácticas de monitoreo especializadas que puedan manejar las características únicas de GraphQL, asegurando un rendimiento eficiente y un funcionamiento confiable. 

GraphQL es una herramienta poderosa que se puede utilizar en una amplia gama de aplicações, desde la creación de API hasta el desarrollo de aplicaciones móviles. Su flexibilidad y capacidad para unificar fuentes de datos lo hacen adecuado para una variedad de patrones de uso diferentes.

1. Creación de API eficientes : Uno de los usos principales de GraphQL es crear API que puedan ser utilizadas por aplicações web y móviles. GraphQL proporciona una forma flexible y poderosa de definir y acceder a datos, lo que lo hace ideal para crear API que necesitan admitir una amplia gama de clientes y casos de uso.
2. Obtención y manipulación de datos : GraphQL se puede utilizar para obtener y manipular datos de una variedad de fuentes, incluidas bases de datos, servicios en la nube y otras API. Al proporcionar una forma unificada de acceder a los datos, GraphQL puede ayudar a simplificar el proceso de creación y mantenimiento de aplicações basadas en datos.
3. Casos de uso en tiempo real : GraphQL es ideal para casos de uso en tiempo real, ya que los clientes pueden suscribirse a actualizaciones de datos específicos y recibir notificaciones cuando los datos cambian. Esto se puede utilizar en aplicações como chat, transmisión en vivo, paneles de control en tiempo real y más.
4. Microservicios : GraphQL se puede utilizar para construir una arquitectura flexible y acoplada de forma flexible que permita que diferentes microservicios se comuniquen entre sí de una manera consistente y bien definida.
5. De back-end a front-end : GraphQL se puede utilizar para construir una arquitectura back-end para front-end (BFF), que permite que diferentes clientes front-end accedan a datos y servicios de forma consistente y eficiente.
6. Desarrollo móvil : GraphQL se puede utilizar para potenciar aplicaciones móviles, proporcionando una forma de acceder a datos y servicios de forma consistente y eficiente, independientemente de la plataforma o el dispositivo. 

Existen motivaciones obvias por las que necesitamos GraphQL, como se ve en las siguientes implementaciones de la industria:

Netflix resumió su trayectoria en GraphQL en 2020 con una serie de blogs de dos partes que es una lectura obligada para cualquier profesional de GraphQL. El caso de estudio que presentaron fue el sistema Studio Edge, que tomó sus API de estudio y las rediseñó para GraphQL. Los equipos de contenido de Netflix utilizan la API Studio para administrar y supervisar la producción, la posproducción y la distribución de programas de televisión y películas. La API proporciona acceso a una gran cantidad de datos, incluidos metadatos sobre títulos, información de talentos y más.

Inicialmente, la API de Studio se construyó utilizando una arquitectura RESTful tradicional, con puntos finales que devolvían datos en formato JSON. Sin embargo, a medida que la API creció y el número de clientes que accedían a ella aumentó, se hizo evidente que se necesitaba una solución más eficiente.

Netflix comenzó a explorar GraphQL como una posible solución para la API de Studio. Empezaron creando un gráfico optimizado para la API de Studio. Identificaron varias ventajas clave, como la capacidad de reducir el uso de la red, simplificar el acceso a los datos y mejorar el rendimiento al permitir que los clientes soliciten solo los datos que necesitan.

Netflix también enfrentó algunos desafíos únicos al adoptar GraphQL para la API de Studio, particularmente en torno a la gestión de la complejidad del esquema y a garantizar que los clientes solo pudieran acceder a los datos que estaban autorizados a ver.

Para abordar estos desafíos, Netflix desarrolló una solución personalizada llamada "Netflix GraphQL Federation", que utiliza la especificación Apollo Federation para dividir el esquema de API de Studio en partes más pequeñas y manejables. También implementaron un sistema de gestión de permisos y control de acceso, que les permite restringir el acceso de los clientes a ciertas partes del esquema.

En el blog también publicaron la evolución de su arquitectura API, desde un Monolito a un Federated Gateway. La figura 5 es una adaptación de la imagen de su blog.

Creemos que falta otro enfoque que puede prevalecer en la industria pero no estar formalizado.

Se podría combinar la capa agregada de puerta de enlace y la puerta de enlace federada de la Figura 5 como se muestra a continuación:

Cada ícono de engranaje representa esencialmente una instancia GraphQL efímera y federada (también conocida como actor de puerta de enlace) que puede instanciarse en tiempo real (incluso por transacción) en el borde, es decir, topológicamente cerca de los clientes y conectarse a los microservicios a través de un transporte API seguro. Esta combinación en esencia reemplaza la capa de agregación de puerta de enlace, o la capa federada, con actores de puerta de enlace distribuidos que combinan lo mejor de ambas funcionalidades. A esta arquitectura de actores de puerta de enlace GraphQL distribuida la llamamos como se muestra en la Figura 7.

PayPal ha estado en el viaje de GraphQL desde2018 Cuando lo incorporaron a su aplicación Checkout, su principal preocupación con REST, al igual que con Meta, era que los principios de diseño no estaban optimizados para las aplicaciones web y móviles y sus usuarios. Las aplicações cliente realizaban numerosos viajes de ida y vuelta desde el cliente hasta el servidor y tardaban aproximadamente 700 ms en obtener los datos. Esto resultó en tiempos de renderizado más lentos, frustración del usuario y tasas de conversión más bajas. Para la aplicación de pago, PayPal descubrió que los desarrolladores de interfaces de usuario (UI) dedicaban menos de un tercio de su tiempo a desarrollar la UI, mientras que el tiempo restante se dedicaba a descubrir cómo obtener y procesar datos.

Las otras tecnologías que consideró el equipo de ingeniería de PayPal fueron las API de orquestación y Bulk REST. La creación de una API de orquestación daría lugar a una sobrebúsqueda y a que los clientes se acoplen al servidor. PayPal concluyó que con el tiempo este enfoque puede provocar que la API se vuelva pesada, torpe y tenga más de un propósito. Su experimento Bulk REST también resultó infructuoso. Si bien liberó al equipo de ingeniería de tener que ajustar las API de orquestación, requirió que sus clientes tuvieran un conocimiento profundo de cómo funcionaban las API.

La primera experiencia de PayPal con GraphQL para crear un nuevo producto fue un SDK móvil para integrar PayPal Checkout en aplicaciones. Una semana después de evaluar GraphQL, el equipo de ingeniería decidió usarlo para su nuevo producto. A pesar de que la API no estaba lista, pudieron completar el producto antes de lo previsto sin necesidad de prácticamente ningún conocimiento específico de PayPal. Los desarrolladores pudieron crear rápidamente una aplicación eficiente y fácil de usar, convenciendo al equipo de ingeniería de adoptar completamente GraphQL en su pila tecnológica. 

Starbuck's contrató a un tercero para desarrollar su Aplicación web progresiva (PWA).

El equipo tenía la tarea de crear un sistema de pedidos que pudiera adaptarse de manera eficiente y eficaz a una lógica empresarial compleja. Como los clientes pueden personalizar sus pedidos, el equipo de desarrollo tuvo que asegurarse de que el sistema pudiera admitir múltiples instancias de lógica comercial única, enviando los datos correctos al lugar correcto en el momento correcto.

GraphQL hizo posible que el equipo creara una API eficiente con almacenamiento en caché y renderizado del lado del servidor para mejorar la funcionalidad sin conexión. El equipo también utilizó React para incorporar animación creando una experiencia de usuario dinámica y atractiva.

El objetivo de la Oficina del CTO de F5 era comprender cómo podíamos utilizar GraphQL dentro del ecosistema de F5. Tenemos dos proyectos en marcha que exploran el uso de GraphQL.

La suite de gestión de pruebas (TMS) ofrecida por F5 brinda a los clientes la capacidad de probar puntos finales o clientes de sus propios sistemas y ver si son humanos o bots.

Este fue un proyecto interno para ayudar a agilizar el desarrollo y las pruebas del software TMS. El objetivo principal era extraer datos JSON atrapados en la base de datos SQL existente, convertirlos en datos gráficos e implementar una API GraphQL para realizar consultas.

Esto fue necesario porque la base de datos actual plantea desafíos, incluido el "problema JSON-blob" que resulta del almacenamiento de metadatos como objetos JSON en una base de datos tabular. Analizar y gestionar estos objetos es inherentemente costoso e ineficiente. Además, los JSON-blobs, debido a su naturaleza gráfica, contienen datos valiosos que pueden mejorar aún más los productos y la seguridad de F5. Al realizar la transición a una base de datos de gráficos dirigidos, los blobs JSON se pueden analizar y administrar de manera eficiente con relaciones dirigidas, lo que optimiza la transferencia y utilización de datos. 

Los resultados son alentadores. Al identificar qué tablas en la base de datos relacional TMS tienen blobs JSON, determinamos que migrar a GraphDB y usar GraphQL podría aumentar nuestra visibilidad en el sistema de muchas maneras. 

La figura 9 muestra las posibles evoluciones u opciones de implementación para este proyecto. Cada elección tiene sus propias implicaciones.

La opción 1 tiene el menor impacto en la interfaz de usuario, ya que el cliente no tiene que cambiar. Un modo híbrido, como en las opciones 1 o 2, puede funcionar bien según la situación, especialmente si hay una menor cantidad de columnas con objetos JSON. Además de esto, el esquema derivado para cada JSON también sería pequeño.

Pero al planificar esto nos dimos cuenta de que los objetos JSON requerían un contexto que estaba almacenado en otras columnas de la base de datos SQL. El tamaño del esquema almacenado en cada objeto JSON también era bastante grande. Esto habría creado más trabajo para mantener la base del código. Entonces, después de una cuidadosa consideración, decidimos rediseñar la aplicação para soportar GraphQL y Neo4J como se muestra en la opción 3.

CloudGraph es una API GraphQL universal, gratuita y de código abierto, y una herramienta de gestión de la postura de seguridad en la nube (CSPM) para AWS, Azure, GCP y Kubernetes (K8s). El objetivo del proyecto es utilizar CloudGraph para crear un «complemento CloudGraph» (Figura 10) para que los datos de F5 Distributed Cloud (F5XC) aparezcan en él, lo que permite una mejor visibilidad de los recursos de la nube conectados mediante F5 Distributed Cloud.

Nuestro objetivo es integrarnos con CloudGraph para obtener una comprensión profunda de la tecnología y crear futuras integraciones, conocimientos y API GraphQL de CloudGraph para los datos de F5XC.

Después de integrar el proveedor F5XC personalizado en la plataforma CloudGraph y utilizar la capacidad de crear relaciones de la plataforma, tendremos una mejor visibilidad de los recursos de la nube conectados mediante F5XC y sus relaciones en otras nubes. Luego podemos generar consultas complejas sobre recursos en múltiples nubes para el mismo inquilino. Esto nos permitirá brindar a las partes interesadas una descripción general completa de F5XC y explorar una integración más profunda de CloudGraph para complementos GraphQL adicionales y conocimientos personalizados para las operaciones en la nube relevantes para F5 y sus clientes.

Basándonos en las iniciativas mencionadas anteriormente, nuestra exploración inicial ha estado en línea con las experiencias esbozadas en los estudios de caso presentados anteriormente.

Las percepciones iniciales sobre la superioridad de GraphQL sobre REST en términos de seguridad han sido desacreditadas, ya que GraphQL, como cualquier otra tecnología, conlleva sus propios riesgos si no se implementa correctamente. Es importante reconocer que GraphQL no es inherentemente más seguro que otras tecnologías. La implementación adecuada y el cumplimiento de las mejores prácticas son cruciales para garantizar la seguridad de las API GraphQL. Al disipar este mito, podemos abordar GraphQL con una comprensión realista de sus consideraciones de seguridad y tomar las medidas adecuadas para mitigar cualquier riesgo potencial.

GraphQL proporciona a los desarrolladores una poderosa herramienta llamada introspección, que les permite solicitar información sobre el esquema utilizado por un servicio GraphQL. Esta herramienta permite a los desarrolladores conocer el servicio y su estructura. Sin embargo, existen riesgos asociados con la introspección. Habilitar la introspección en un servicio GraphQL de producción significa que también se puede acceder a información confidencial dentro del esquema. Esto supone un riesgo importante, ya que usuarios maliciosos pueden aprovechar la introspección para obtener datos confidenciales y potencialmente causar daños. Además, la introspección otorga a estos usuarios la capacidad de identificar fácilmente operaciones potencialmente dañinas, ya que pueden ver el esquema completo y determinar qué consultas ejecutar. Las consecuencias de tal fuga pueden ser desastrosas, dependiendo de la naturaleza del esquema y de los datos que contenga.

Mitigación : Una solución para mitigar los riesgos de la introspección es deshabilitarla en las API de producción utilizando varios marcos. Al deshabilitar la introspección, los desarrolladores pierden algunas de las funciones convenientes que ofrece. Sin embargo, para recuperar su usabilidad, los desarrolladores pueden registrar el esquema GraphQL de la API de producción con herramientas como GraphOS. Esto les permite mantener el acceso controlado al esquema y su información.

La inyección SQL es un ataque ampliamente reconocido y frecuente que plantea riesgos que van desde la manipulación de datos hasta la eliminación completa de la base de datos. Este ataque directo aprovecha la concatenación de cadenas, lo que permite a un atacante insertar código ejecutable dentro de la entrada, otorgando acceso no autorizado a la base de datos y posibilitando alteraciones maliciosas. Curiosamente, este vector de ataque no se limita únicamente a las bases de datos SQL, sino que también puede afectar a bases de datos gráficas como Neo4j. Neo4j emplea el lenguaje de consulta Cypher, que se parece a SQL y hereda sus vulnerabilidades. Este tipo de ataque, conocido como inyección Cypher, explota las similitudes pero también se beneficia de las soluciones existentes sin necesidad de nuevas invenciones.

Mitigación : Las contramedidas incluyen la desinfección de la entrada del usuario para detectar y prevenir la explotación y el uso de parametrización para abstraer la entrada del usuario de la creación de consultas directas. Estas medidas mitigan eficazmente el riesgo de ataques por inyección. Es crucial abordar este problema de seguridad en las implementaciones de GraphQL, pero afortunadamente existen soluciones conocidas y fácilmente implementables. 

Colocar una API GraphQL sobre una API REST puede generar vulnerabilidades de falsificación de solicitudes del lado del servidor (SSRF). Los atacantes pueden aprovechar esto modificando los parámetros enviados a la API REST a través del proxy GraphQL. Si ninguna API valida los parámetros para llamadas específicas, los atacantes obtienen control del sistema backend. Por ejemplo, agregar "/delete" a un ID de usuario en una consulta GraphQL puede generar la eliminación no intencionada de datos cuando se pasan a la API REST.

Mitigación : Si bien esta vulnerabilidad es una preocupación válida, se puede abordar de manera efectiva definiendo tipos en el esquema GraphQL y validando exhaustivamente los parámetros antes de enviarlos a API o servicios externos. Es importante tener en cuenta que esta vulnerabilidad, junto con otras asociadas con GraphQL, se origina en problemas de implementación en lugar de ser problemas inherentes a GraphQL en sí. Estos problemas surgen cuando se hace un mal uso de GraphQL debido a una mentalidad cortoplacista, a pesar de que la tecnología es muy prometedora.

Las vulnerabilidades de autenticación son un vector de ataque predominante en varios sistemas, incluido GraphQL. La capacidad de GraphQL de enviar múltiples consultas o mutaciones en una sola solicitud lo expone a ataques por lotes, que involucran métodos de fuerza bruta.

El primer tipo de ataque implica la fuerza bruta de las contraseñas de inicio de sesión. Los atacantes envían una solicitud con numerosas mutaciones que contienen pares de credenciales de inicio de sesión. Dado que GraphQL permite muchas mutaciones en una solicitud, este ataque evita los controles de limitación de velocidad y permite la creación de una sesión mediante la fuerza bruta de las contraseñas.

El segundo tipo de ataque funciona de manera similar, pero apunta a una forma popular de autenticación de dos factores (2FA) llamada contraseña de un solo uso (OTP). Se envía una única solicitud con múltiples mutaciones, cada una de las cuales contiene una credencial de inicio de sesión válida emparejada con una variación de OTP diferente. Si alguna de las mutaciones incluye el OTP correcto, se autenticará la solicitud y se establecerá una sesión.

Mitigación : Para abordar estas vulnerabilidades se necesita un enfoque integral, ya que no existe una solución infalible. Los desarrolladores desempeñan un papel crucial al adoptar prácticas de codificación seguras y enfatizar la perspectiva de la lógica empresarial. En el lado del servidor web, es esencial implementar medidas como limitar los intentos de inicio de sesión y validar la entrada del usuario. Además, se debe prestar especial atención a las solicitudes de escaneo de múltiples mutaciones, ya que un intento de inicio de sesión legítimo normalmente no implica más de una mutación.

Estos ataques implican saturar el servicio GraphQL con tráfico excesivo, dejándolo incapaz de manejar solicitudes de usuarios legítimos y potencialmente provocando fallas del servidor. Los ataques DoS se pueden ejecutar a través de consultas GraphQL recursivas o enviando solicitudes de consulta grandes.

En el escenario de consulta recursiva, los atacantes explotan la naturaleza cíclica de las definiciones de esquema GraphQL. Por ejemplo, si el esquema incluye los tipos de autor y libro, un atacante puede consultar repetidamente el autor y el libro en un bucle, abrumando al servidor con llamadas recursivas e interrumpiendo su funcionamiento.

Alternativamente, los atacantes pueden emitir consultas que soliciten una gran cantidad de datos de la base de datos. Por ejemplo, una consulta puede recuperar muchos autores y todos sus libros asociados. Una solicitud de datos tan masiva puede ralentizar o bloquear significativamente el sistema .

Mitigación : Existen varias soluciones para mitigar este problema. El primer enfoque es establecer un tiempo de espera para las consultas, evitando que los usuarios realicen solicitudes que excedan una duración específica. Sin embargo, esto puede no resolver el problema por completo, ya que aún podrían producirse daños dentro del tiempo asignado. Otra solución es imponer límites a la profundidad y complejidad de las consultas. Las consultas que superen la profundidad o complejidad designada y se desvíen de la definición del esquema pueden rechazarse. Por último, implementar una limitación de usuarios puede ser eficaz. Si un usuario envía un conjunto grande o consecutivo de solicitudes, su acceso al servidor puede ser denegado temporalmente hasta que el servidor esté preparado para manejar solicitudes adicionales.

Hay varios patrones de implementación para GraphQL como se muestra, cada uno con su propio conjunto de compensaciones y consideraciones. Algunos de los patrones más comunes incluyen:

Este es el patrón más simple y común para implementar una API GraphQL. En una implementación monolítica, el servidor GraphQL, la base de datos y cualquier otro servicio necesario se implementan juntos como una sola unidad. Esto puede hacer que sea fácil comenzar a usar GraphQL, pero puede resultar difícil escalarlo y mantenerlo a medida que la aplicação crece. 

Los monolitos compuestos se refieren a la arquitectura donde se construye una aplicação monolítica utilizando una combinación de monolitos y microservicios con GraphQL actuando como capa de API (Figura 12). En este patrón, en lugar de dividir todo el sistema en microservicios separados, la aplicação se desarrolla inicialmente como monolitos separados, que encapsulan toda la lógica empresarial y las capas de acceso a datos. 

Dentro de esta estructura monolítica, GraphQL se implementa como la capa API, lo que permite a los clientes solicitar y recuperar datos de diferentes microservicios subyacentes. Esto significa que, si bien la aplicação sigue siendo monolítica desde una perspectiva de implementación, utiliza GraphQL como un medio para componer datos de varios servicios y presentarlos a los clientes de manera flexible y eficiente.

Este patrón ofrece beneficios como un desarrollo y una implementación simplificados, así como la capacidad de aprovechar las potentes capacidades de consulta y obtención de datos de GraphQL. Permite a los desarrolladores adoptar progresivamente la arquitectura de microservicios y al mismo tiempo beneficiarse de la flexibilidad y facilidad de uso que ofrece GraphQL. 

Los gráficos federados en los patrones de implementación de GraphQL implican la combinación de múltiples servicios GraphQL, llamados subgráficos, en un único esquema GraphQL unificado. Cada subgráfico representa un dominio o microservicio separado con sus propios datos y funcionalidad. Esta arquitectura utiliza una puerta de enlace central que dirige las consultas del cliente al subgráfico apropiado en función de los campos solicitados. Al federar estos subgráficos, los desarrolladores pueden crear un gráfico cohesivo donde los clientes pueden consultar y navegar sin problemas entre diferentes servicios.

Este enfoque promueve la modularidad, la escalabilidad y el desarrollo independiente de servicios, lo que resulta en un mejor rendimiento y flexibilidad para crear API GraphQL. Los subgráficos federados (Figura 13) proporcionan una forma poderosa de componer datos de varios servicios y crear una arquitectura distribuida y escalable.

Los gráficos híbridos (Figura 14) en los patrones de implementación de GraphQL combinan subgráficos federados y esquemas no federados a través de técnicas de unión. Este enfoque permite a las organizaciones integrar API GraphQL existentes o sistemas heredados con microservicios federados, lo que da como resultado una API GraphQL unificada que se beneficia de ambos enfoques. Al fusionar esquemas y resolver relaciones entre tipos y campos, la arquitectura gráfica híbrida ofrece flexibilidad, modularidad y escalabilidad.

El patrón de gráfico híbrido brinda a las organizaciones la capacidad de adoptar gradualmente la federación mientras aprovechan sus recursos existentes. Permite la integración perfecta de subgráficos federados y esquemas no federados, adaptándose a diversos requisitos y promoviendo la interoperabilidad. Este enfoque permite a las organizaciones crear API GraphQL integrales que pueden escalar y adaptarse a las necesidades cambiantes. Al combinar las fortalezas de los servicios federados y no federados, los gráficos híbridos ofrecen una solución flexible y poderosa para crear implementaciones GraphQL.

Los desafíos con los gráficos híbridos en las implementaciones de GraphQL incluyen la gestión de la complejidad de los esquemas fusionados, abordar la posible sobrecarga de rendimiento, garantizar la coherencia e integridad de los datos, manejar la evolución y el control de versiones del sistema, y navegar por las complejidades del monitoreo y la depuración en una arquitectura distribuida. Estos desafíos requieren una planificación cuidadosa, optimización y prácticas de desarrollo sólidas para superarlos y garantizar el buen funcionamiento de las implementaciones de gráficos híbridos. 

Este patrón implica implementar la API GraphQL como un conjunto de funciones sin servidor, como AWS Lambda o Google Cloud Functions. Esta puede ser una forma rentable y escalable de implementar una API GraphQL, pero también puede introducir latencia adicional y aumentar la complejidad de la arquitectura.

El enrutamiento sin servidor presenta muchos desafíos. Un problema es conectar sin problemas subgráficos distribuidos a medida que la aplicação se expande. La coordinación de varios equipos e implementaciones puede resultar compleja, lo que dificulta la gestión y escalamiento efectivo de los subgráficos. Garantizar la coherencia de los datos y la sincronización entre estos subgráficos es otro obstáculo. La supervisión y la depuración en un entorno distribuido sin servidor pueden ser más difíciles y requieren mecanismos adecuados de registro y manejo de errores. Además, gestionar el control de acceso y la autorización en múltiples funciones y subgráficos sin servidor plantea desafíos. Abordar estos desafíos es esencial para el buen funcionamiento y la escalabilidad de una implementación de GraphQL basada en servidor.

En un patrón de implementación de borde para las API GraphQL, la API se ubica más cerca de los clientes mediante un servicio CDN. Esto trae varios beneficios, incluida una menor latencia para respuestas más rápidas, una carga reducida en el servidor de origen y protección contra ataques DDoS.

Al distribuir la infraestructura de API en servidores perimetrales de todo el mundo, se puede gestionar el tráfico de forma más eficiente y brindar una mejor experiencia de usuario a nivel global. Las capacidades de almacenamiento en caché y filtrado de la CDN ayudan a mejorar la escalabilidad y garantizar la disponibilidad de la API, incluso frente a tráfico pesado o ataques maliciosos. Las implementaciones de borde tienen el potencial de optimizar el rendimiento y la confiabilidad de una API al aprovechar la red de servidores de las CDN. 

Las tecnologías GraphQL han madurado lo suficiente como para ser adoptadas por las empresas tradicionales. Si bien el Hype Cycle de Gartner para API 2022 indica que aún faltan varios años para su adopción generalizada, ya hemos llegado a un punto de inflexión crítico en el que ya contamos con las herramientas necesarias. Si bien GraphQL todavía es relativamente nuevo, ha evolucionado hasta el punto de poder satisfacer las necesidades de empresas establecidas y de gran escala.

La madurez de las tecnologías GraphAPI tiene su origen en el creciente número de empresas que adoptan GraphQL y otras tecnologías de bases de datos gráficas. A medida que más y más empresas adoptan estas tecnologías, las herramientas y los recursos necesarios para apoyarlas están cada vez más disponibles, lo que hace más fácil que otras empresas sigan su ejemplo. Además, los beneficios de las tecnologías GraphAPI (como la consulta mejorada de datos y la menor complejidad) están siendo cada vez más reconocidos, lo que impulsa aún más su adopción entre las empresas.

Como industria, debemos reconocer la importancia de las tecnologías GraphAPI como GraphQL y su potencial para superar las limitaciones de REST. Las empresas no deben pasar por alto la necesidad urgente de invertir en GraphQL y comprenderlo, particularmente en términos de modelado de datos, diversidad y opacidad. Si bien es fácil enamorarse de las características y el potencial de GraphQL, también debemos reconocer el posible bajón de desilusión después de alcanzar expectativas infladas. Los proveedores deben priorizar la mejora de sus productos para que sean totalmente compatibles con GraphQL, mientras que la TI empresarial (incluidos los proveedores) debe identificar qué datos se beneficiarían de la exposición a GraphQL para mejorar la productividad.

Los clientes deben priorizar la comprensión de sus datos y reconocer que una empresa promedio opera de manera diferente a los hiperescaladores que originalmente introdujeron GraphQL. Trabajemos juntos para adoptar GraphQL como un patrón de arquitectura de software eficaz e impulsar la industria hacia una mejor productividad e innovación.

Descargar el informe