Header Ads Widget

Ticker

6/recent/ticker-posts

REST vs GraphQL: cómo las restricciones determinan el estilo de la API

 



Mucho se ha dicho sobre REST y GraphQL . Desafortunadamente, estas conversaciones casi siempre giran en torno a la idea de que uno es mejor que el otro; la mayoría de las veces, GraphQL se presenta como el siguiente paso hacia un mundo sin REST . Desafortunadamente, eso es engañoso, perjudicial y pasa por alto el panorama general de la industria.

Hoy, vamos a ver de dónde viene este llamado “zeitgeist de la frustración” y por qué es incorrecto aplicarlo a nuestra conversación sobre estilos de diseño de API web . Analizaremos la naturaleza de esta conversación en su conjunto y buscaremos métodos mejores y más efectivos para elegir la tecnología correcta.

Este artículo se basa en la fantástica presentación realizada por Zdenek Nemec en la Cumbre de Plataformas 2018 de las API nórdicas :

Manzanas y naranjas: paradigmas API

“Voy a dejar algunas cosas claras aquí. Uno es un estilo arquitectónico, eso es DESCANSO. El otro es un lenguaje y un marco. Ambos se pueden usar para construir sistemas distribuidos, para construir servicios y API. Así que pienso en estas cosas, aunque [GraphQL y REST] son ​​cosas ligeramente diferentes, como paradigmas de API ".

Antes de entrar en conversaciones más detalladas sobre el razonamiento subyacente detrás de estas comparaciones, deberíamos hablar sobre la comparación en sí. Al comparar REST con GraphQL, es un error considerar este tema como una batalla entre dos cosas similares. La realidad es que REST y GraphQL se parecen solo en el hecho de que son soluciones tecnológicas; sin embargo, sus implementaciones reales y sus estructuras, enfoques y diseños subyacentes difieren lo suficiente como para hacer que esta comparación sea de “ manzanas y naranjas ”.

No estamos comparando Python y Javascript aquí; lo que en realidad estamos haciendo es comparar paradigmas , que es un enfoque completamente diferente que no encaja bien con la idea de que uno sea mejor que el otro en un sentido general. Los paradigmas son fundamentalmente diferentes de otros tipos de soluciones, como los lenguajes, específicamente debido a su usabilidad de base amplia: un paradigma es una solución para un problema dado, no para todos los problemas. En consecuencia, un paradigma puede, de hecho, ser apropiado en un caso de uso específico y, por lo tanto, "mejor" que el otro, mientras que simultáneamente en un caso de uso separado, lo contrario es cierto; en otras palabras, el paradigma debe ser juzgado por el situación, no por medidas cualitativas o cuantitativas.

Por estas razones, comparar GraphQL y REST es menos como comparar, digamos, un Tesla Roadster y un Ford Mustang. En esa comparación, tenemos dos tecnologías que en general tienen el mismo propósito, y aunque los requisitos del usuario pueden hacer que una sea más apropiada que la otra, la capacidad fundamental de moverse del punto A al punto B no se logra en una contra la otra. Comparar un paradigma es más como comparar los viajes en tren y en avión de alta velocidad. Para muchos casos de uso, viajar en avión es más apropiado; sin embargo, si moviéramos carga o una distancia de 10 km, entonces un tren sería mucho más apropiado. Las razones por las que existe cada paradigma no son mutuamente excluyentes, por lo que es difícil decir "¿por qué usar el tren de alta velocidad cuando tenemos aviones?"

En pocas palabras, la comparación "versus" aquí es desafortunada y está mal formada.

REST vs GraphQL: El Zeitgeist de la frustración

“Muchos [artículos] dicen algo como“ DESCANSAR en paz REST ”y“ Hurra GraphQL ”Pero si miras hace poco tiempo en el pasado, había artículos similares solo con diferentes palabras en los titulares - era REST y SOAP . […] Hay gente infeliz, con los estilos actuales o predominantes. Tienen problemas, y los proveedores REST o los servicios web SOAP no escucharon esos problemas, por lo que la historia se repite ".

Con eso en mente, ¿de dónde viene esta conversación? Si cada opción vale la pena para un propósito determinado, ¿por qué estamos tentados a pensar en términos de "todo o nada"? Esta comparación tiene sus raíces en el espíritu de la frustración que sienten tanto los desarrolladores como los usuarios por sus escenarios dados. Al principio del espacio de las API web, SOAP era el rey de las API financieras y cualquier relación transaccional que requiriera un estado. Pronto, se desarrolló REST, y el tema de jure se alineó con la idea de que REST era el "asesino de SOAP", la tecnología que finalmente nos liberaría del férreo control estatal del paradigma SOAP.

La realidad, por supuesto, es que SOAP fue perfecto para lo que fue diseñado, y la invención de REST no cambió eso. REST fue un paso adelante en la pila de tecnología, claro, pero vino junto con desarrollos que requerían procesamiento sin estado y contratos relacionales, y como tal, llenó un nuevo nicho que se estaba desarrollando en el mundo de las API. Entonces, hubiera sido más apropiado decir simplemente que REST era un nuevo enfoque fuera de SOAP, no un asesino de SOAP, ni siquiera un reemplazo, sino un nuevo enfoque.

Esta es una distinción importante. En muchos sentidos, esta idea de que una solución es mejor que la otra en todos los casos es realmente perjudicial para la comunidad de usuarios y desarrolladores en el espacio API. Adoptar una relación de todo o nada con soluciones de este tipo significa que los desarrolladores se propusieron desarrollar primero una API REST, no una API que esté correctamente diseñada. En muchos casos, esto se puede hacer apropiado mediante el uso de bibliotecas o marcos, pero es preocupante proponerse hacer una solución a un problema en lugar de permitir que el problema defina una solución.

La mejor solución, entonces, es mirar realmente las restricciones en juego y formar una estimación del valor de su solución API, en lugar de esperar que su solución sea universalmente efectiva. Las restricciones dictan soluciones y, en última instancia, ayudan a guiar su elección contra lo que es apropiado, en lugar de seguir el espíritu de la época de los usuarios frustrados que sugieren su propia implementación "perfecta".

Estilos arquitectonicos

“El estilo arquitectónico es un conjunto de restricciones que, al aplicarlas, implicarán un sistema con ciertas propiedades ... Por ejemplo, tome una restricción donde los componentes de mi sistema deben estar desacoplados. El cliente debe estar desacoplado del servidor. Eso implica, si esa restricción se mantiene, que puede evolucionar independientemente el cliente o el servidor. Una restricción de "desacoplamiento" implica una evolución independiente de ambos componentes ".

Antes de sumergirnos en tipos específicos de restricciones , también debemos considerar el estilo arquitectónico . En muchos casos, la propia arquitectura de la API determinará el mejor enfoque para la solución de su problema.

Como arquitecto de API que crea una API potente y funcional, su papel principal es decidir y comprender. Primero debe esforzarse por comprender el paradigma bajo el que está operando, por ejemplo, si su implementación es una colección de microservicios, una API de mensajería, etc., y cuáles son las implicaciones de ese paradigma. Con esto en mente, debe tomar una decisión: dada su arquitectura y el paradigma de desarrollo que ha elegido, ¿cuál cree específicamente que es la mejor opción para el ecosistema de API creado dado?

Esto es extremadamente importante, especialmente si se considera que REST y GraphQL ni siquiera son las soluciones predominantes en toda la industria de las API. Esta conversación tiende a ser frustrada por aquellos que están atrapados en las minucias de las opciones de la competencia; en muchos casos, el mundo empresarial todavía usa SOAP. En consecuencia, usar una solución RESTful cuando su servicio principal es SOAP y su API requiere el almacenamiento de un estado es una tontería.

Las restricciones deben determinar el estilo

“Cuando los colonos en el siglo XVIII estaban colonizando América, estaban construyendo edificios coloniales. Estaban en un entorno donde tenían muchas limitaciones a su alrededor. No tenían la tecnología adecuada para construir con mal tiempo. No podían tener una gran ventana de vidrio… Estaban construyendo casas coloniales porque eran colonos y tenían casas coloniales. ¿Adivina qué estamos haciendo hoy? Decimos "Me gustan mucho las API REST o las API GraphQL, y creo que voy a crear una". Probablemente eso no sea lo que queremos hacer. Tenemos algunas limitaciones a nuestro alrededor que tenemos que escuchar ".

Según el modelo de Nemec, hay cuatro tipos básicos de restricciones :

  • Restricciones comerciales : las restricciones comerciales son lo que el producto debe cumplir. Es qué tarea debe completarse y cuál es el caso de uso. En esencia, estos tipos de restricciones son aquellos elementos de la API que proporcionan valor comercial y operativo y justifican la existencia real de la API en sí.
  • Restricciones de complejidad : estas restricciones son el nivel de complejidad aceptable o requerida en la solución implementada. En muchos casos, es posible que se requiera que una API sea eficiente, pequeña y autónoma; en esos casos, se prefiere una menor complejidad. Por otro lado, si la API debe ofuscar algunas de sus funcionalidades o cifrar sus flujos de datos , esto introducirá una complejidad que debe abordarse. Algunas veces, estos requisitos están determinados por componentes: cuando la API se conecta a una amplia variedad de servidores, tanto locales como remotos, este recuento puro de componentes dará como resultado una API más compleja que una simple pila de red.
  • Restricciones de dominio : estas restricciones incluyen regulaciones comerciales, gubernamentales o industriales. Estos tipos de regulaciones pueden definir cómo opera específicamente su API; al menos, puede dictar cómo se protegen los datos en tránsito y en reposo, lo que puede resultar en diferencias en las tecnologías implementadas.
  • Restricciones culturales : la cultura de su organización, así como la base de usuarios con la que pretende trabajar, a menudo también dictarán implementaciones específicas. Un ejemplo de ello sería la Ley de Conway, que dice que, como organización, usted está esencialmente destinado a crear un sistema que imite sus patrones de comunicación interna. En consecuencia, cuando tiene diferentes partes de una organización que no se comunican de la misma manera, esto dará como resultado opciones específicas de lenguaje y paradigma y, en algunos casos, introducirá restricciones de dominio adicionales.

En última instancia, estas limitaciones son mucho más importantes que cualquier beneficio tecnológico prometido por cualquier solución y, como tales, serán el marco sobre el que se basarán sus elecciones.

Para leer más, consulte nuestro libro electrónico: GraphQL o Bust

Las restricciones dictan propiedades

"Por otro lado, si aplica algunas restricciones, puede obtener algunas propiedades".

Las restricciones forman el aspecto de su solución en forma de Propiedades. Las propiedades son el resultado final de cada restricción aplicada a la solución del mundo real, ya que la restricción predice, y casi todas las determina, las propiedades del sistema final. Estas propiedades se pueden clasificar en términos generales en rendimiento, escalabilidad y simplicidad.

  • Propiedades de rendimiento : estas propiedades definen el rendimiento del sistema subyacente. Este rendimiento puede variar entre la velocidad de cada llamada y la capacidad de recuperarse de errores.
  • Propiedades de escalabilidad : estas propiedades determinan qué tan fácil es para el implemento escalar horizontalmente. La capacidad de escalar determina en gran medida si la solución es costosa por nodo o si es capaz de agregar sistemas adicionales sin la sobrecarga singular asociada incurrida por el sistema central.
  • Propiedades de simplicidad : estas propiedades determinan qué tan compleja o simple es realmente la implementación, ya sea en términos de código o en términos de arquitectura física.

Estas propiedades son el producto de cada restricción ejecutada en el caso de uso y pueden ayudar a determinar la solución real elegida. Las restricciones regulatorias para el cifrado o hash, la auditabilidad, la transparencia o incluso la trazabilidad de las llamadas podrían determinar la propiedad bajo la cual se juzga el proceso. Por supuesto, esto podría resultar en complejidad o, en algunos casos, simplicidad en el hecho de que todas las llamadas deben enrutarse de una manera única y segura.

Por otro lado, algo así como una API relacional que se vincule a los medios enriquecidos a través de gráficos sociales daría como resultado una propiedad de simplicidad que requiere interacciones complejas; de esta manera, se exige complejidad al sistema.

Decidir por restricciones y propiedades

Con todo esto en mente, podemos ver que esto es menos una cuestión de lo que es mejor y más de lo que es más apropiado. Las consideraciones cuando se trata de este espacio varían ampliamente y dependen completamente de su implementación específica. Estas consideraciones pueden hacer que adopte diferentes tecnologías por razones y propósitos muy diferentes y, por lo tanto, no es apropiado llamar a ningún paradigma "mejor" que el otro.

Por ejemplo, si tiene una red compleja de API, REST podría ser una mejor opción, ya que puede aprovecharlas para el desarrollo de microservicios, y su mapeo ya está limitado de forma natural: no es necesario que GraphQL mapee datos de microservicio en una red normal de API. Por otro lado, digamos que la misma red luego genera una API shim que es de acceso público, y estos datos deben ser aprovechables en una amplia gama de formatos según lo determine el usuario, en este caso, porque GraphQL permite llamar a datos. en un formato específico determinado por el usuario, es la opción adecuada, incluso si la red interna se basa en REST

Conclusión

En pocas palabras, preguntar qué es lo mejor entre REST y GraphQL es una consideración errónea. Zdenek Nemec hace un buen resumen en su presentación. Según sus sugerencias, REST es una buena opción cuando necesita construir un sistema centrado en la longevidad, la negociación de contenido, la autenticación precisa o la limitación de la tasa de autorización; GraphQL, por otro lado, es más apropiado cuando se realizan rutas de comunicación frontend-backend, reemplazando implementaciones de cuasi-resto y brindando una buena experiencia de desarrollador con una experiencia mínima.

En cualquier caso, el zeitgeist no debería determinar su elección en el paradigma, solo las restricciones y sus propiedades resultantes deberían hacerlo. Hacer cualquier otra cosa es tomar una decisión desinformada, que tiene sus propios costos y aspectos negativos.

Publicar un comentario

0 Comentarios