Phil Sturgeon publicó recientemente un
tweet que golpeó mucho a los fanáticos de GraphQL. Este tweet habló sobre cómo GraphQL es, por definición, una tecnología que contradice la esencia de HTTP / 2. El hecho de que el estándar HTTP / 3 ya se haya lanzado y que el autor del tweet realmente no entienda a aquellos que, al elegir GraphQL, siguen el camino de la incompatibilidad. Para comprender mejor las razones de la actitud de Phil hacia GraphQL, eche un vistazo a
este material.
Casi al mismo tiempo, se hizo un anuncio sobre el proyecto
Vulcain . Este mensaje incluía las palabras: "TL / DR: GraphQL que ya no necesita". Y finalmente, se publicó un gran
artículo de Mark Nottingham sobre las potentes funciones de HTTP / 2 y lo que esas características significan para quienes diseñan la API. Darrel Miller
compartió un enlace a este artículo con sus suscriptores.
Lo que estaba sucediendo me hizo pensar en GraphQL y HTTP / 2. Si todo comienza a funcionar con HTTP / 2 (y HTTP / 3), ¿significará que no tenemos ninguna razón para usar GraphQL? Me gustaría saberlo hoy.
Innovaciones HTTP / 2
Para comenzar, descubramos qué puede afectar la tecnología HTTP / 2 al valor de GraphQL a los ojos de los desarrolladores. HTTP / 2 tiene mucho que ofrecer. Este es, por ejemplo, un nuevo formato binario y una compresión de encabezado mejorada. Pero en nuestro caso, el papel principal lo juega la forma en que se procesa la entrega de solicitudes y respuestas cuando se utiliza HTTP / 2.
Abrir una conexión TCP es una operación costosa. Los clientes que usan HTTP / 1 tienden a no ejecutarlo con demasiada frecuencia. Por esta razón, debido a la gran carga adicional en el sistema, los desarrolladores a menudo intentaron limitar el número de solicitudes recurriendo a una variedad de tecnologías. Esto, por ejemplo, ejecutar consultas por lotes, usar lenguajes de consulta, incrustar código CSS / JS en el código de la página, usar hojas de sprites en lugar de imágenes individuales, etc. En HTTP / 1.1. Se intentó resolver algunos de estos problemas utilizando conexiones persistentes y procesamiento de datos
canalizado . Estas dos tecnologías permitieron a los navegadores enviar, dentro de la misma conexión, varias solicitudes y recibir respuestas a ellas. La desventaja de un esquema de intercambio de datos de este tipo era que estaba sujeto al problema de bloquear el comienzo de la cola (
bloqueo de encabezado de línea ). Este problema se expresa en el hecho de que una solicitud lenta puede ralentizar el procesamiento de todas las solicitudes que le siguen. Los expertos que trabajaron en HTTP / 2 sugirieron diferentes formas de resolver este problema. Junto con el nuevo protocolo binario, HTTP / 2 presenta una nueva estrategia de entrega de datos. Durante la interacción de los sistemas que utilizan el protocolo HTTP / 2, se abre una única conexión, dentro del marco de la cual se realiza la multiplexación de solicitudes y respuestas utilizando un nuevo nivel binario diseñado para trabajar con cuadros, cuando cada cuadro es parte de un flujo. Con este mecanismo, los clientes y servidores pueden recrear los flujos de solicitud y respuesta en función de la información sobre ellos que se encuentra en los marcos. Esto permite que HTTP / 2 soporte de
manera muy
efectiva el procesamiento de muchas solicitudes que se ejecutan dentro de una sola conexión.
Pero eso no es todo. HTTP / 2 tiene un nuevo concepto llamado Server Push. Si no entra en detalles, entonces podemos decir que esta tecnología permite que los servidores envíen datos a los clientes por adelantado, haciendo esto antes de que los clientes soliciten estos datos. Los ejemplos más llamativos de este comportamiento son el envío anticipado de hojas de estilo y recursos de JavaScript a los clientes. En el proceso de generar una respuesta a la solicitud HTTP, el servidor puede descubrir que se necesita algún archivo CSS para representar la página HTML, y descubrir de antemano que el cliente lo contactará pronto para este archivo. Esto permite que el servidor envíe el archivo dado al cliente incluso antes de que el cliente lo solicite. Así es como funciona el proyecto
Vulcain antes mencionado, utilizando esta tecnología para organizar la carga eficiente de los recursos relacionados.
Entonces, mientras todo está claro. Pero, ¿qué tiene que ver todo esto con GraphQL?
GraphQL: una consulta que resuelve todos los problemas
La tecnología GraphQL se debe en parte a su atractivo, ya que ayuda a los desarrolladores a hacer frente a las desventajas típicas de las conexiones HTTP / 1.
Es por eso que GraphQL permite a los clientes, en una sesión comunicarse con el servidor, cumplir con las solicitudes para recibir casi cualquier cosa. Esto puede contrastarse con la API Hypermedia, cuando se usa, lo que generalmente necesita para realizar muchas solicitudes de red (a veces, sin embargo, el
almacenamiento en caché puede mejorar la situación).
La capacidad de recibir múltiples recursos dentro de una sola consulta es una de las fortalezas de GraphQL , a la cual los creadores de esta tecnología atraen la atención de sus usuarios potenciales.Muchos de los que dicen que nadie necesita la tecnología GraphQL con el advenimiento de HTTP / 2 significan esta posibilidad. El uso de API por lotes, lenguajes de consulta (como GraphQL), optimización de relaciones e incluso creación de puntos finales agregados, ahora parece menos atractivo que antes. La cuestión es que el "costo" de realizar consultas se vuelve pequeño. Y eso es verdad. ¿Pero es solo por eso que usamos GraphQL? No lo creo
¿Quizás el hecho es que ahora todavía son los primeros días de los clientes HTTP / 2 y algunas aplicaciones de servidor?
No creo que la pregunta planteada en el título de esta sección sirva como una explicación digna del hecho de que todavía estamos usando GraphQL ampliamente. Pero vale la pena mencionarlo. El uso de HTTP / 2 a nivel de aplicación en algunos ecosistemas es un desafío que está lejos de resolverse. Busque, por ejemplo, las palabras "Rack / Rails over HTTP / 2". Será interesante La cuestión es que muchas partes del servidor de las aplicaciones se crean utilizando el patrón de solicitud / respuesta. Como resultado, cambiar al concepto de flujos HTTP / 2 no es tan simple. Especialmente, en el caso de algunos marcos. Pero esta es una excusa indigna, muchos ecosistemas soportan perfectamente tal esquema de interacción entre clientes y servidores, y, en teoría, aún deberíamos esforzarnos por mejorar dicha interacción. (La mayoría de los servidores proxy también admiten esto, pero no es fácil organizar algo como enviar datos a un cliente por iniciativa del servidor si la aplicación del servidor está atascada en el pasado usando un patrón de solicitud / respuesta).
GraphQL es más que reducir el tiempo de recepción y transmisión de datos, u optimizar la cantidad de información transmitida
Si bien la reducción del tiempo de recepción y transmisión de datos y la optimización de la cantidad de información transmitida son las fortalezas de GraphQL de las que escuchamos constantemente, esta tecnología nos brinda mucho más.
El poder de la tecnología GraphQL radica en su enfoque en los sistemas cliente. El cliente es el entorno en el que GraphQL hace muchos compromisos. En los últimos años, esto ha molestado a muchos. Entonces, Daniel Jacobson escribió muchos buenos artículos sobre algunos de estos problemas hace 5-7 años.
Aquí y
allá , un par de sus publicaciones. Él dice en uno de ellos: "Nuestras API REST, aunque son capaces de manejar solicitudes generales, no están optimizadas para ninguna de estas solicitudes".
Tenga en cuenta que esta idea es válida no solo cuando se aplica a la tecnología REST. Las aplicaciones cliente a menudo tienen que realizar más solicitudes de servidor de las que desearían sus desarrolladores. Estas aplicaciones tienen que lidiar con la recepción de datos innecesarios de los servidores. Se trata más de diseñar API que sería bueno crear para que admitan muchos usos diferentes. La forma habitual de resolver este problema es tener la lógica del cliente lo más cerca posible de la lógica del servidor. Un ejemplo de este enfoque son los adaptadores de cliente de Netflix mencionados en
este artículo de 2012. Desde entonces, algunos equipos de Netflix incluso han
cambiado a GraphQL. El patrón
BFF también está dirigido a resolver tales problemas.
La tecnología GraphQL está cambiando el concepto de la frontera entre el cliente y el servidor, ayudándonos a crear sistemas de servidor que pueden incluir información sobre cómo serán utilizados por los clientes. Esto se manifiesta claramente cuando se utiliza la tecnología de solicitudes
constantes , ya que aquí estamos hablando, en esencia, de los recursos del servidor generados por iniciativa del cliente.
Cuando piense en la relevancia de GraphQL en el mundo HTTP / 2, recuerde que estamos hablando de la abstracción del servidor. La compatibilidad con una variedad de casos de uso de datos del servidor puede generar problemas en las API tradicionales basadas en puntos finales. GraphQL permite a quienes admiten la API concentrarse en ofrecer a los usuarios de estas API una amplia gama de características. Al mismo tiempo, los propietarios de la API pueden no preocuparse por la creciente carga en los clientes existentes, y que el soporte para la API se volverá mucho más complicado debido a la necesidad de soportar muchos recursos diferentes. (La compatibilidad con muchos recursos diferentes tiene sus inconvenientes. Por lo tanto, tales esquemas complican la optimización del rendimiento. Tales recursos no siempre están bien almacenados en caché. Las API que pueden ajustarse en gran medida enfrentan los mismos problemas).
Desarrollo de sistemas cliente y GraphQL
En este artículo, hablo principalmente de servidores, pero es importante recordar que los desarrolladores de clientes son muy aficionados a la tecnología GraphQL. Si combina fragmentos GraphQL con el enfoque de componentes de los marcos front-end modernos, obtendrá una abstracción completamente sorprendente. Y, de nuevo, si agregamos consultas constantes aquí, podemos decir que GraphQL hace la vida más fácil para los desarrolladores de sistemas cliente.
GraphQL es un sistema holístico con características notables.
GraphQL no es algo que tenga capacidades completamente únicas. Hay alternativas a este sistema. Esquema escrito? ¡Lo mismo ocurre con OpenAPI! ¿Abstracciones del servidor que admiten diferentes casos de uso del cliente? Esto se puede implementar de muchas maneras. Introspección? El uso de Hypermedia permite a los clientes descubrir acciones y comenzar a trabajar con la entidad raíz. ¿Una deliciosa herramienta GraphiQL? Estoy seguro de que se creó algo similar para OpenAPI. Las posibilidades de GraphQL siempre se pueden recrear utilizando otras tecnologías. Sin embargo, GraphQL es un sistema holístico. Esto es lo que atrae a una audiencia tan grande de desarrolladores a GraphQL que están felices de usar este sistema. Sospecho que esta es una de las razones de la rápida expansión y desarrollo de GraphQL. Además, dado que la construcción de GraphQL-API está bien documentada, las bibliotecas GraphQL diseñadas para diferentes lenguajes suelen ser de alta calidad y popularidad.
La red sigue siendo un factor limitante (¿o tal vez siempre será así?)
Aquí hay otro pensamiento en el que quiero pensar. Existe la sensación de que la red, cuando se trata de trabajar con la API, siempre desempeñará el papel de algún factor limitante. No importa lo rápido que sean las solicitudes de red. Es por eso que no diseñamos API web de la misma manera que los objetos comunes utilizados en diferentes lenguajes de programación.
Aquí , por ejemplo, estamos hablando de por qué las interfaces con un alto nivel de detalle no son muy adecuadas para crear sistemas diseñados para trabajar con ellas de forma remota.
Si bien HTTP / 2 definitivamente alienta la ejecución de solicitudes con gran granularidad, creo que hay algunas compensaciones que hacer aquí.
¿Puede HTTP / 2 ayudar a GraphQL?
Entonces, GraphQL le brinda al desarrollador muchas herramientas importantes y útiles, pero HTTP / 2 también es una gran tecnología. Miremos hacia el futuro y pensemos en los beneficios que los sistemas GraphQL pueden beneficiarse al usar HTTP / 2. Por ejemplo, podría verse así:
query { viewer { name posts(first: 100) @stream { title } } }
Resulta que podemos usar la abstracción del lado del servidor de GraphQL, el lenguaje de consulta declarativa de esta tecnología, y al mismo tiempo usar las capacidades de las secuencias HTTP / 2. Creo que los sockets web se usan aquí. Todavía necesito resolver esto, pero estoy seguro de que muchos ya están explorando directivas
@defer como
@defer ,
@stream y
@live .
Resumen
HTTP / 2 es una gran tecnología (y los ejemplos que se dan
aquí son solo algún tipo de milagro). GraphQL solo se puede percibir como una tecnología que reduce la cantidad de sesiones de comunicación cliente-servidor o ayuda a optimizar el volumen de datos transmitidos. Si es así, cualquiera que vea GraphQL desde una perspectiva similar estará muy contento de usar API basadas en capacidades HTTP / 2. Sin embargo, si ve en GraphQL una combinación de tecnologías que le dan al desarrollador muchas cosas útiles, queda claro que el poder de GraphQL no se limita en absoluto a mejorar el uso de los recursos de la red y ahorrar tráfico.
Estimados lectores! Si utiliza la tecnología GraphQL, díganos qué es lo que no le gusta más.
