Header Ads Widget

Ticker

6/recent/ticker-posts

¿GraphQL es el final de las API de estilo REST?

 

GraphQL vs REST API Design

El mundo de las API es uno de innovación e iteración constante. Las tecnologías que alguna vez impulsaron las mejores y más grandes soluciones en la web han sido suplantadas por soluciones nuevas e innovadoras.

Por eso es sorprendente, entonces, que muchos desarrolladores se hayan aferrado a lo que consideran los bastiones del desarrollo de API web. Tal bastión es la arquitectura REST . Para algunos desarrolladores, REST es una propuesta obsoleta e incompleta que no cumple con muchas de las nuevas calificaciones de desarrollo requeridas por los desafíos únicos que enfrentan los grupos de desarrollo modernos.

Hoy, veremos una tecnología que está lista para reemplazar, o al menos, cambiar drásticamente la forma en que se diseñan y presentan las API : GraphQL . Discutiremos un poco de historia, qué problemas sufre REST y qué hace GraphQL de manera diferente.

Esta es una pieza complementaria de una charla impartida por Joakim Lundborg de Wrapp en la Cumbre de la Plataforma de APIs nórdicas de 2016.

"La forma en que diseñamos nuestras API estructura la forma en que pensamos [sobre] las herramientas y aplicaciones que creamos".

Definición de REST y sus limitaciones

REST o Representational State Transfer, es una arquitectura de diseño de API desarrollada para extender y, en muchos casos, reemplazar estándares arquitectónicos más antiguos. Los objetos en REST se definen como URI direccionables , y normalmente se interactúa con los verbos incorporados de HTTP , específicamente, GET, PUT, DELETE, POST, etc. En REST, HATEOAS (Hypermedia As The Engine Of Application State) es un Restricción de arquitectura en la que el cliente interactúa con enlaces hipermedia, en lugar de a través de una interfaz específica.

Con REST, el concepto central es que todo es un recurso . Si bien REST fue una gran solución cuando se propuso por primera vez, hay algunos problemas bastante importantes que padece la arquitectura. Según Lundberg, las circunstancias han cambiado, dando lugar a la necesidad de nuevas implementaciones técnicas:

“Han pasado muchas cosas. Tenemos muchos dispositivos móviles con muchas aplicaciones sociales y muy ricas en datos que se están produciendo ... Ahora tenemos clientes muy poderosos y tenemos datos que están cambiando todo el tiempo. Esto trae algunos problemas nuevos ".

Aquí hay algunos problemas que Lundberg ve con REST:

Tiempos de ida y vuelta y repetición

La característica definitoria de REST es la capacidad de referenciar recursos ; el problema es cuando esos recursos son complicados y relacionales en una organización más compleja conocida como gráfico . La obtención de estos gráficos complicados requiere viajes de ida y vuelta entre el cliente y el servidor y, en algunos casos, viajes repetidos para las condiciones de la red y los tipos de aplicaciones.

En última instancia, esto da como resultado un sistema en el que cuanto más útil es, más lento es . En otras palabras, a medida que se presentan más datos relacionales, el sistema se ahoga.

Recuperación por encima / por debajo

Debido a la naturaleza de REST y los sistemas que a menudo usan esta arquitectura, las API de REST a menudo resultan en una búsqueda excesiva o insuficiente. La recuperación excesiva es cuando se obtienen más datos de los necesarios, mientras que la recuperación insuficiente es lo contrario, cuando no se entregan suficientes datos al realizar la recuperación.

Cuando se crea por primera vez un URI de recurso, todo está bien: se entregan los datos necesarios para la funcionalidad y todo está bien. A medida que la API aumenta en complejidad y, por lo tanto, los recursos también aumentan en complejidad, esto se vuelve problemático.

Las aplicaciones que no necesitan todos los campos o etiquetas lo reciben todo como parte del URI. Las soluciones para solucionar esto, como el control de versiones , dan como resultado un código duplicado y una "espaguetificación" de la base del código. Yendo más allá, limitar específicamente los datos a un URI de bajo contenido que luego es extensible da como resultado una mayor complejidad y la obtención deficiente resultante en consultas mal formadas.

Ver 10 proveedores de API que ya implementan GraphQL

Escritura débil y metadatos deficientes

Desafortunadamente, las API REST a menudo sufren de una mala escritura . Si bien muchos proveedores de API y comentaristas argumentan este problema (a menudo con la advertencia de que HTTP en sí mismo contiene un sistema de escritura), las soluciones del sistema de campo que se ofrecen simplemente no coinciden con la amplia gama y el alcance de los datos disponibles para la API.

Específicamente, este es un argumento a favor de la escritura fuerte en lugar de la escritura débil. Mientras que hay soluciones que ofrecen a escribir, la delimitación entre débil y fuerte es la cuestión aquí, no es un argumento desactivado diciendo simplemente “así no es escribir”. La fuerza y la calidad de la tipificación hace cuestión.

Esto es más una cuestión de edad y movilidad que un problema intrínseco, por supuesto, y puede corregirse utilizando varias soluciones (de las cuales GraphQL es una).

Lea también: Cómo envolver una API REST en GraphQL

Uso inadecuado de la arquitectura

REST sufre por el hecho de que a menudo se usa para algo para lo que no fue realmente diseñado y, como resultado, a menudo debe modificarse en gran medida. Eso no quiere decir que REST no tenga su lugar, solo quiere decir que puede que no sea la mejor solución para servir aplicaciones cliente. Como dice Facebook en su propia documentación :

“Estos atributos están vinculados al hecho de que“ REST está diseñado para aplicaciones de red de larga duración que abarcan varias organizaciones ”, según su inventor . Este no es un requisito para las API que sirven a una aplicación cliente creada dentro de la misma organización.

Todo esto es para decir que GraphQL es funcionalmente el final de REST, pero no en la forma que implica la terminología. Hasta ahora, REST ha sido visto como la arquitectura fundamental de las API modernas y, en cierto modo, el último bastión del diseño de API clásico.
El argumento aquí no está hecho para separar completamente REST de nuestro léxico arquitectónico, sino más bien para reconocer que hay varios problemas importantes que no se rectifican de manera adecuada y completa con las soluciones que a menudo ofrecen sus proponentes.
Por lo tanto, la respuesta a la pregunta de este artículo: ¿GraphQL es el fin de las API de estilo REST? - es bastante simple. Sí, el uso de GraphQL es el final de las API de estilo REST tal como las conocemos, específicamente a través de la extensión de la funcionalidad base y una reconsideración de las relaciones y funciones de datos.

4 cosas que GraphQL hace mejor que REST

"GraphQL declara todo como un gráfico ... Dices lo que quieres y luego lo obtendrás".

Ahora que hemos visto los problemas con REST, ¿cómo, exactamente, los resuelve GraphQL?

REST tiene muchos viajes de ida y vuelta, GraphQL tiene pocos

El mayor beneficio de GraphQL sobre REST es el simple hecho de que GraphQL tiene menos viajes de ida y vuelta que REST, y más eficientes. GraphQL unifica datos que de otro modo existirían en varios puntos finales (o peor aún, puntos finales ad hoc) y crea paquetes.

Al empaquetar los datos, la entrega de datos se hace más eficiente y disminuye la cantidad de recursos necesarios para las llamadas de ida y vuelta. Esto también reestructura fundamentalmente la relación entre cliente y servidor, poniendo más eficiencia y control en manos de los clientes GraphQL.

REST tiene sistemas de tipos deficientes: GraphQL tiene uno sofisticado

Si bien REST puede tener un sistema de tipos a través de implementaciones de HTTP, REST en sí no tiene un sistema de tipos muy sofisticado. Incluso en buenas implementaciones, a menudo termina con variantes de configuraciones de tipo, por ejemplo, clientdatamobile y clientdatadesktop , para adaptarse a las llamadas estándar REST.

GraphQL resuelve esto con un sistema de escritura muy sofisticado, que permite consultas más específicas y poderosas.

REST tiene poca capacidad de detección: GraphQL tiene soporte nativo

La capacidad de detección no es nativa de REST y requiere implementaciones específicas y metódicas de HATEOAS , Swagger y otras soluciones similares para que sea completamente reconocible. La clave allí es "totalmente detectable": sí, REST tiene HATEOAS como un sistema de descubrimiento "nativo", pero carece de algunos elementos importantes de detección efectiva , a saber, estructura de documento conocida, estructuras de restricción de respuesta del servidor e independencia del error restrictivo estándar. mecanismos en HTTP.

Si bien este y muchos otros puntos de consideración negativa hacia REST a menudo se responden con "¡pero puede agregar esa funcionalidad!", El hecho de que carece de ella de forma predeterminada solo aumenta la complejidad de la que estamos tratando de alejarnos.

Debido a que GraphQL se basa en datos relacionales y, cuando se opera en un esquema correctamente formado, es autodescriptivo, GraphQL se puede descubrir de forma nativa por diseño. La capacidad de detección es increíblemente importante, tanto en términos de permitir la funcionalidad e interacciones extensibles de terceros como para los desarrolladores y usuarios incorporados con un sistema de funciones fácil de entender y explorar.

REST es Thin Client / Fat Server - GraphQL es Fat Client / Fat Server

En el diseño REST, la relación entre cliente y servidor está bien definida, pero desequilibrada . REST utiliza un cliente muy ligero , según el procesamiento del servidor y los puntos finales que se han definido para él. Dado que la mayor parte del procesamiento y el control se coloca firmemente en el servidor , esto le quita energía al cliente y también acentúa los recursos del lado del servidor. Hasta ahora eso ha estado bien, pero a medida que los dispositivos crecen en capacidad y capacidad de procesamiento, esta relación cliente / servidor puede necesitar un replanteamiento.

GraphQL, sin embargo, es diferente. Al descargar la especificación del formato de datos esperado al cliente y estructurar los datos alrededor de esa llamada en el lado del servidor, tenemos un Fat Client / Fat Server (o incluso un Thin Client / Thin Server según el enfoque) en el que tanto el poder como el control están nivelados a través de la relación.

Esto es muy poderoso cuando se considera que el tipo de datos que se solicita se utilizará para fines específicos según lo regulado y solicitado por el propio Cliente; tiene sentido, entonces, que pasar de una relación Thin / Fat a Fat / Fat o Thin / La relación delgada mejoraría esta funcionalidad en el lado del Cliente al tiempo que liberaría recursos del Servidor. Por supuesto, esto supone que el cliente es capaz de manejar esta carga.

Para obtener una descripción general de REST, lea: Diseño de una verdadera máquina de estados REST

El fin del status quo

Existe una tendencia en el espacio tecnológico de los proveedores y desarrolladores de nuevas tecnologías a proclamar el fin de una era con cada solución. Si bien es común la discusión en el campo, el hecho es que hay muy pocos cambios completos de paradigma que señalen un fin irrevocable a las tecnologías existentes.

La innovación depende de tecnologías anteriores para crear nuevas funciones. Por lo tanto, cuando se diseña una nueva solución, no reemplaza la solución, sino que itera. Lo mismo es verdad aquí. Si bien GraphQL puede no ser la desaparición completa de REST, es el final del status quo . Si bien hay muchas soluciones a los problemas que se plantean aquí, todas dependen de integraciones y modificaciones adicionales. GraphQL es esencialmente una revisión y mejora la funcionalidad de nivel base de la propia API.

Conclusión

Lo que tenemos aquí es una propuesta de valor básica. GraphQL hace bien lo que hace, pero la cuestión de la integración radica directamente en qué tipo de datos está procesando y qué problemas está creando su API. Para las API simples, REST funciona bien, pero a medida que los datos se vuelven más complejos y las necesidades de los proveedores de datos aumentan, también lo hará la necesidad de sistemas más complejos y potentes.

La adopción de GraphQL como complemento o extensión de la ideología REST , mientras se elimina REST del espacio intelectual de "demasiado grande para no usar", resultará directamente en API más potentes con una capacidad de descubrimiento más fácil y una mayor capacidad de administración de los datos que manejan.

Publicar un comentario

0 Comentarios