Header Ads Widget

Ticker

6/recent/ticker-posts

¿La multiplexación HTTP hace obsoleto GraphQL?



El espacio de la API es algo propenso a la idea de que algo sea el "asesino de XYZ": las nuevas soluciones se enmarcan como revolucionarias o causas de obsolescencia para su competencia. Recientemente, esto se ha convertido en un tema relacionado con HTTP / 2 y GraphQL . Como HTTP / 2 ve una mayor difusión del conocimiento, algunos se han preguntado si algunas de sus características reemplazan la necesidad de GraphQL. Este pensamiento es de esperar, dado que HTTP / 2 tiene muchos aspectos que se centran en solicitudes multiplexadas y entrega asincrónica . Entonces, la pregunta "¿No es eso lo que hace GraphQL?" es natural.

Hoy, vamos a profundizar en HTTP / 2 y GraphQL para responder a eso. Examinaremos el problema fundamental que subyace a ambas soluciones, los síntomas que están diseñados para aliviar y los resultados finales de esos esfuerzos. Veremos cómo se ve la multiplexación en ambas soluciones, y luego veremos si una hace que la otra sea obsoleta o no.

El problema con HTTP / 1

Antes de profundizar en las diferencias (y similitudes) entre HTTP / 2 y GraphQL, es útil comprender primero el problema central en la implementación de HTTP / 1 . HTTP / 1 (y su colección precursora) es de una era en la que la transferencia de datos era relativamente ligera en comparación con la actualidad. En un momento en el que una solicitud masiva era de cientos de bits, en lugar de los flujos de datos de megabit (y a veces gigabit) habilitados por los estándares actuales, HTTP / 1 cumplió su propósito, entregando datos a través de una conexión estable.

Sin embargo, el problema viene con el aumento de los tamaños de los paquetes: abrir una conexión TCP en HTTP / 1 es costoso y estas solicitudes tienen una sobrecarga alta. En consecuencia, las solicitudes grandes pronto se volvieron insostenibles a través de una sola conexión, lo que resultó en los intentos de HTTP / 1.1 de entregar dichos datos a través de conexiones persistentes y canalizaciones . Este enfoque, que combina múltiples solicitudes y respuestas en una sola conexión, funcionó bien durante un tiempo. Aún así, expuso varios problemas; uno de estos problemas fue el bloqueo del encabezado de línea, que permitió que una solicitud lenta bloqueara todo lo demás en la misma conexión, lo que introdujo nuevamente el problema de conexión.

Un problema adicional introducido por esta congestión es la entrega fuera de servicio. Este problema surge cuando los paquetes se ven obligados a seguir diferentes rutas de conexión después de que se caen y se vuelven a enviar. Este problema casi abrumadoramente es causado por la congestión o las conexiones débiles entre el cliente y el servidor, con grandes solicitudes, y esto puede resultar en salidas de datos casi completamente inútiles. Si bien existen algunas soluciones para esto (en particular multidifusión), en última instancia, se trata de curitas sobre el problema más importante.

Soluciones de GraphQL al problema HTTP / 1

La solución de GraphQL a este problema fue trasladar el paradigma de solicitud al cliente y permitir que el cliente solicite todos los recursos a la vez. Si bien la idea de "empaquetar" múltiples solicitudes en una sola solicitud puede parecer contradictoria, le permite al cliente solicitar solo lo que realmente desea. Al permitir que los clientes obtengan todos los datos expuestos por el servidor en un solo viaje, las solicitudes se empaquetaron en una solicitud única y limpia que podría ser atendida con menos gastos generales y tiempo de devolución.

Quizás lo más importante es que este paradigma ofreció una solución al problema de la obtención de más y de menos. En la interacción normal en HTTP / 1, era más probable que una solicitud no contuviera suficientes datos o que contuviera una gran cantidad de "datos basura" que el servidor creía necesarios, pero que el cliente no quería. Si bien esto fue probablemente pequeño en la mayoría de los casos, en toda una red, este error de cálculo de búsqueda significó más solicitudes duplicadas y más transformaciones de clientes, lo que agravó los problemas subyacentes con HTTP / 1.

Lo que cambió HTTP / 2

HTTP / 2 tiene muchas soluciones que se ofrecen, y una de las más importantes es la forma en que maneja tales solicitudes. HTTP / 2 permite la multiplexación de solicitudes de una manera muy eficiente, reduciendo el costo general de dichas solicitudes y respuestas. Además, al empaquetar las respuestas utilizando una capa de trama binaria (en la que cada trama es parte de una secuencia y se puede combinar en la solicitud de mayor transmisión), dichas llamadas se reducen en tamaño general y se hacen mucho más eficientes.

Otra ganancia importante en HTTP / 2 es Server Push . En pocas palabras, Server Push permite a los servidores enviar respuestas a un cliente antes de que soliciten los datos. Esto reduce la necesidad de solicitudes entrantes y reduce la congestión del tráfico, que a menudo es el resultado de muchas solicitudes no especializadas. Por ejemplo, no es raro que un sitio web cargue una hoja de estilo. Como tal, un servidor puede servir automáticamente este contenido usando Server Push, en lugar de esperar a que el cliente envíe una segunda solicitud después de la solicitud de conexión. Si bien esto no afecta el tamaño de la solicitud en sí, reduce la congestión en el canal de entrada y, por lo tanto, libera recursos de manera significativa.

Lea también: ¿Qué viene en HTTP / 3 Quic?

¿HTTP / 2 logra objetivos similares a GraphQL?

Si todo esto suena un poco a que HTTP / 2 está diseñado para reemplazar GraphQL , eso es solo parcialmente correcto. En realidad, los aspectos de GraphQL ahora se encuentran integrados en HTTP / 2 y HTTP / 3 . Sin embargo, la realidad es que estos aspectos son solo una pequeña parte de la oferta de GraphQL; en pocas palabras, HTTP / 2 no reemplaza GraphQL por un par de razones importantes.

El valor real detrás de GraphQL no es su capacidad de multiplexación. La importancia detrás de GraphQL es el cambio de paradigma del centrismo del servidor al centrismo del cliente. En un paradigma centrado en el servidor, el servidor le dice al cliente lo que necesita y luego el cliente solicita más información. El problema final con este enfoque es que nadie sabe más que el cliente lo que quiere el cliente. Por lo tanto, el flujo de trabajo de comunicación se convierte en una mezcla de conjeturas (ver: Supuestos de Server Push) y casos extremos inesperados (por ejemplo, un navegador sin cabeza puede no querer, o necesitar, una hoja de estilo).

En GraphQL, cuando un cliente solicita datos, los está solicitando para un uso y función muy específicos, y el formulario que solicita está destinado a un propósito muy específico. Como tal, una solicitud GraphQL es la transformación de un recurso general en uno específico según los requisitos del solicitante. Con HTTP / 2, puede hacer mucho de lo que hace GraphQL en términos de reducir los problemas generales de ida y vuelta y recuperación, pero en última instancia, aún está codificando para un solo caso de uso.

De hecho, incluso si codifica para una multitud de casos de uso y envía esas solicitudes por activación circunstancial (por ejemplo, es posible crear un paradigma en el que una conexión móvil según lo informado por los encabezados del navegador obtenga una respuesta de API móvil a través de HTTP / 2 ), todavía está agregando una capa de ofuscación desde el punto de entrada hasta la estructura de datos subyacente. Esto no solo agrega más congestión (ya que ahora se necesita una capa de enrutador de código lógico o API), sino que también agrega complejidad.

Considere un recurso GraphQL que sirva a un sitio web con datos: podría tener un navegador sin cabeza, un navegador de escritorio, un navegador móvil y un complemento, todos solicitando el mismo recurso por razones muy diferentes. Cada uno de estos casos de uso puede necesitar un tipo particular de datos entregados para algunas necesidades particulares. HTTP / 2 puede, en teoría, atender estas solicitudes, pero solo está agregando complejidad adicional y, en algunos casos, es posible que esté enviando más datos de los necesarios.

Por ejemplo, es posible que los dispositivos móviles no necesiten todos los datos a la vez y, en su lugar, solo deseen una "instantánea" con pocos datos del estado actual, que se puede ampliar a pedido. Es posible que el escritorio no esté limitado en absoluto, y puede que solo solicite todo en una explosión. Las opciones sin cabeza no necesitan contenido gráfico y, como tal, los flujos de datos pueden optimizarse para eliminar este contenido, reduciendo así el tamaño del flujo. En la mayoría de las implementaciones de HTTP / 2, cada una de estas estructuras debería crearse explícitamente, formando una extraña colección de microservicios de respuestas HTTP / 2 con un controlador o un monstruo de Frankenstein de enrutamiento y filtrado de respuestas.

El cliente debe definir este tipo de relaciones con el servidor, no al revés. Ciertamente, hay casos en los que esto no es cierto, por ejemplo, la transmisión de audio solo cambia la tasa de bits, no el contenido de entrega, pero para tipos de contenido más dinámicos, esta relación no se sirve mejor con HTTP / 2.

Definiendo los paradigmas

En última instancia, la cuestión de si HTTP / 2 hace que GraphQL sea obsoleto es un malentendido de cuáles son las soluciones. En lenguaje sencillo, son dos paradigmas muy diferentes y, como tales, no son equivalencias 1: 1 .

GraphQL es un paradigma en el que el cliente determina qué datos obtiene y en qué formato. HTTP / 2 es un paradigma en el que el servidor determina qué datos obtiene el cliente y en qué formato. Si bien los dos paradigmas se pueden piratear para permitir una multitud de relaciones diferentes, esta estructura subyacente no cambia y representa los conceptos centrales para los que fueron diseñados.

Conclusión

La conclusión de todo esto es una declaración simple: no, HTTP / 2 no hace obsoleto GraphQL. Decir como tal es un poco como decir que el automóvil quedó obsoleto por el avión; sí, técnicamente ambos hacen lo mismo (llevarlo del punto A al punto B), pero ambos ofrecen muchas más características y diferencias entre sí que el la comparación se vuelve una especie de tontería fuera del cruce específico en esa forma y función específicas.

GraphQL hace mucho más que multiplexar. Hasta que HTTP / 2 y HTTP / 3 tengan soporte para la determinación del lado del cliente de la forma y estructura de los datos y la obtención de datos declarativos del cliente (es decir, la capacidad de solicitar datos y hacer que el servidor los filtre y combine, en lugar de que el cliente solicite múltiples puntos finales), GraphQL definitivamente tendrá un propósito . Más concretamente, la idea de que haya una solución omnibus que reemplace GraphQL al por mayor no es buena: GraphQL existe para un propósito específico, y hasta que haya una solución que sea literalmente todo para todos, debería haber un caso de uso individual. -Implementaciones específicas que se ofrecen.

¿Qué piensas? ¿Crees que HTTP / 2 y HTTP / 3 eventualmente reemplazarán a GraphQL? ¿Crees que debería pasar? Háganos saber en los comentarios a continuación.

Publicar un comentario

0 Comentarios