Header Ads Widget

Ticker

6/recent/ticker-posts

El poder de la retransmisión; El punto de entrada a GraphQL


 En muchos sentidos, GraphQL es un enfoque futurista para lidiar con todos los dolores de cabeza que rodean la transferencia de datos y el contenido relacional de gran volumen. A medida que se escribe más sobre la tecnología y se discute su implementación, no hace falta decir que los componentes relacionados también son cada vez más interesantes.

Uno de estos componentes, Relay , a menudo se queda en el camino en la conversación, y eso es una pena, dado que Relay es increíblemente poderoso, útil e interesante, dados los casos de uso adecuados.

En consecuencia, esta pieza se centrará en Relay como una extensión de GraphQL según las pautas de desarrollo y la documentación declaradas de Facebook Discutiremos cómo Relay hace lo que hace, qué lo hace específicamente especial y por qué emparejar Relay con algunas, pero no todas, implementaciones de GraphQL es una buena idea.

¿Cuál es la diferencia entre Relay y GraphQL?

Si bien GraphQL y Relay a menudo se insertan en la misma oración (y Facebook y muchos otros defensores los tratan como un paquete ), en realidad son dos partes muy diferentes de un mecanismo mayor.

¿Cuál es la diferencia entre GraphQL y Relay?

GraphQL es, fundamentalmente, una forma de modelar y exponer datos en la aplicación nativa. Es decir, GraphQL es la metodología mediante la cual se prepara toda su funcionalidad extendida para la búsqueda y la interacción.

Relay, por otro lado, es la solución de obtención de datos del lado del cliente que se vincula con este modelo establecido para representar datos de manera eficiente para el usuario final. Se relaciona con el esquema GraphQL, usa el esquema GraphQL y, con más adiciones del lado del servidor, aumenta el esquema GraphQL, pero decir que son uno en el mismo es como decir que "gasolina" y "neumáticos" son uno en el lo mismo porque ambos se usan para impulsar un automóvil.

Para llevar aún más a casa el punto, GraphQL se puede usar de forma totalmente independiente de Relay, mientras que Relay depende de GraphQL (o, al menos, esquemas similares a GraphQL) para funcionar. GraphQL se puede utilizar con cualquier tecnología de búsqueda que esté diseñada para manejar la consulta en cuestión (lo que se hace fácilmente con la mayoría de las soluciones modernas).

La especificación GraphQL describe cómo Relay hace tres suposiciones básicas sobre lo que proporciona un servidor GraphQL:

  1. Un mecanismo para recuperar un objeto.
  2. Una descripción de cómo navegar por las conexiones.
  3. Estructura alrededor de mutaciones para hacerlas predecibles.

¿Qué es Relay?

Entonces, ¿qué es exactamente Relay? En su nivel más básico, Relay es un marco de JavaScript diseñado para construir servicios React.js . Fue diseñado como un componente de GraphQL de Facebook, diseñado expresamente para manejar un alto rendimiento de datos y generar los datos solicitados de forma dinámica.

Un gran punto de poder detrás de Relay es cómo maneja esta búsqueda de datos. Relay maneja datos a través de declaraciones declarativas en GraphQL, componiendo la consulta de datos en lotes eficientes mientras se mantiene la estructura de datos establecida. Debido a esto, Relay es muy rápido , muy eficiente y, lo que es más importante, extensible a las demandas de la aplicación de manera dinámica.

Eso no es lo único que hace que los usuarios de Relay canten sus elogios, por supuesto. La colocación está presente en Relay, lo que permite consultas agregadas y búsqueda limitada. Las mutaciones también son ampliamente compatibles y proporcionan actualizaciones optimistas para crear una experiencia de usuario más fluida al presentar los datos como un rendimiento positivo incluso cuando el servidor aún está administrando la solicitud.

Básicamente, Relay hace lo que hace bien, en aplicaciones muy específicas y de manera más eficiente que otras soluciones.

Relacionado Cómo envolver una API REST en GraphQL

El bueno

Entonces, con todo esto en mente, ¿por qué usar Relay? Si GraphQL hace tanto y funciona fuera de Relay, ¿por qué lo necesitamos? Bueno, GraphQL no es perfecto. Carece de la capacidad de sondear y actualizar de forma reactiva, y tiene algunas ineficiencias integradas que hacen que el sistema no sea óptimo.

Relay, por otro lado, soluciona muchos de estos problemas, extendiendo su utilidad a nuevas alturas. Con Relay, los requisitos de datos se establecen expresamente y se obtienen de manera mucho más eficiente que la búsqueda estándar en GraphQL. Este aumento en la eficiencia se debe en gran parte al almacenamiento en caché de datos integrado en Relay, lo que permite que los datos existentes se reutilicen en lugar de forzar una nueva búsqueda para cada viaje de ida y vuelta en el servidor.

Parte de este aumento en la eficiencia proviene de la agregación y colocación de consultas en solicitudes de datos únicas y optimizadas. Si bien esto tiene un gran beneficio en términos de lógica, el principal beneficio está en el tráfico de red y la reducción volumétrica pura.

Las mejoras no se detienen ahí. Relay ofrece mutaciones eficientes y permite catalogar, almacenar en caché y alterar estas mutaciones después del hecho, incluida la alteración dinámica de columnas / valores.

Un gran beneficio aquí es el soporte para actualizaciones optimistas . Las actualizaciones optimistas son una metodología interesante de mutaciones de clientes en la que el cliente simula la mutación a medida que el servidor envía la mutación al backend, lo que permite al usuario interactuar con los cambios que realizaron y simular su experiencia sin esperar a que el servidor se comprometa.

Como parte del soporte para actualizaciones optimistas, Relay proporciona un sistema para actualizaciones de mutación de Relay, informes de estado y reversión, lo que permite una gestión más fluida de los estados del cliente y del servidor. Relay también admite la paginación enriquecida , lo que alivia la pesada carga de los grandes retornos de datos y los hace más fáciles de consumir, mejorando aún más la experiencia del usuario.

Podemos ver la efectividad de Relay al observar su implementación. La aplicación de mensajería Drift está diseñada para utilizar la mensajería en tiempo real de forma nativa en el sitio web del proveedor. Debido a experiencias previas con múltiples puntos finales y grandes solicitudes de datos, el equipo de Drift sabía que la velocidad se vería afectada, y dramáticamente.

Cuando comenzaron una nueva empresa, Drift, y se vieron cayendo en el mismo agujero que antes, tomaron la decisión de solucionar el problema desde el principio e integraron GraphQL en sus servicios. Ante el siguiente conjunto de datos complejos:

Los atributos del cliente provienen de una sola solicitud que devuelve nombre, título, ubicación, zona horaria y avatar. Pero para mostrar el propietario de la cuenta, necesitaremos consultar el punto final del equipo de la organización para buscar ese nombre y avatar. Para representar esas coloridas etiquetas, necesitamos buscar las definiciones de etiquetas de otro punto final. La lista de todos los avatares de contacto requiere una búsqueda de todos los clientes de la misma empresa en nuestro backend ElasticSearch. El recuento de chat y el último contacto requieren varias llamadas a nuestra API de conversación y una última llamada para obtener el estado en línea de ese usuario o la última marca de tiempo activa.

Codificaron la siguiente consulta de datos:

{
user(id:1) {
   name
   title
   avatarUrl
   timezone
   locale
   lastSeenOnline
   email
   phone
   Location
  accountOwner {
     name
     avatarUrl
   }
   tags {
     edges {
       node {
         label
         color
       }
     }
   }
   accountUsers(first:10) {
     edges {
       node {
         id
         avatarUrl
       }
     }
     pageInfo {
       totalAccountUsers
     }
   }
   recentConversations(first:10) {
     edges {
       node {
         lastMessage
         updatedAt
         status
       }
       pageInfo {
         totalConversationCount
       }
     }
   }
 }
}

¿Su reacción?

Pudimos expandir nuestra consulta en función de las necesidades del cliente y solicitar una tonelada de información que normalmente habría tomado múltiples solicitudes, una gran cantidad de repetición y código innecesario escrito tanto en el cliente como en el servidor. lo que el cliente quería y le da al servidor la capacidad de optimizar los recursos necesarios para calcular la respuesta. Lo mejor de todo es que todo esto se hizo en una sola solicitud. Increíble. Bienvenido al futuro.

Bienvenidos al futuro, de hecho.

Para obtener más información, consulte: 5 beneficios potenciales de la integración de GraphQL

El malo

Hay muchas cosas buenas sobre Relay, pero hay algunos problemas subyacentes detrás de cada beneficio. Tomemos, por ejemplo, la idea del manejo de mutaciones dentro del propio Relay. Cuando ocurren mutaciones, especialmente cuando se realizan en un paradigma de actualización optimista, se encuentran algunos problemas importantes.

Por ejemplo, al consultar una base de datos con varios campos en el esquema GraphQL, esencialmente está actualizando el cliente varias veces, el backend varias veces y esperando que la parte del gráfico relacionada se actualice correctamente. Nueve de cada diez veces lo hacen, pero incluso una sola falla podría tener un efecto continuo en el backend en general.

Además, la idea de actualizaciones optimistas es excelente en teoría, pero agrega cierta responsabilidad lógica en el desarrollador del lado del cliente que puede ser útil o no en todos los casos de uso. Si bien las ediciones grandes definitivamente se beneficiarían de este esquema de actualización, las actualizaciones y mutaciones simples no requieren simulación. Lo que esto significa es una gran cantidad de lógica que se debe implementar en el equipo del lado del cliente, y el equipo del lado del servidor tiene muy poca responsabilidad para garantizar la compatibilidad cruzada.

Por supuesto, también existe la preocupación por la pérdida de datos y la validación en dicho sistema. Con cada nivel creciente de complejidad en esta situación, está reduciendo la eficiencia que hace que Relay sea una venta tan buena en primer lugar.

Sin embargo, el principal problema planteado hacia Relay es que no es técnicamente necesario ; si bien la funcionalidad de Relay es impresionante, hay un conjunto de soluciones únicas y ya integradas en lenguajes y arquitecturas comunes que reflejan la funcionalidad de tal manera que Relay podría simplemente estar reinventando la rueda.

GraphQL estándar se puede utilizar sin Relay, especialmente en proyectos con un alcance menor que Facebook, sin mucha pérdida de funcionalidad. Otras soluciones como Cashay reflejan la solución de almacenamiento en caché para estados de dominio en un formato más simple y fácil de usar.

Un reemplazo de descanso

Ha habido cierta controversia sobre exactamente por qué necesitamos Relay, o incluso GraphQL, para el caso. El desarrollo de GraphQL y Relay proviene de la idea de que hay algo fundamentalmente mal o mal hecho en REST , una perspectiva con la que no todos están de acuerdo.

Indiquemos por adelantado que casi todo lo que hace GraphQL se puede hacer en REST, aunque quizás con menos eficiencia. Obtener gráficos de objetos complejos es más fácil en GraphQL, pero la misma funcionalidad se puede replicar construyendo un punto final alrededor de los conjuntos de datos dados como un subconjunto del todo mayor.

Estas solicitudes complejas se facilitan con el hecho de que HTTP puede enviar solicitudes de red paralelas , aunque con una mayor sobrecarga. Y qué limitaciones existen en esta solución actual, HTTP / 2 está intentando resolverlas, y (en algunas opiniones) con gran efecto.

También está el problema de qué están diseñados para manejar Relay y GraphQL. Los dos fueron desarrollados por Facebook para Facebook, un sitio que se ocupa de miles de puntos de metadatos y relaciones que el desarrollador promedio nunca puede encontrar. En este caso, para muchas personas, se trata de matar las malas hierbas con un lanzallamas; sí, es una solución, pero es una sobre ingeniería .

Una buena parte de las críticas hacia GraphQL y Relay en principio es el hecho de que muchos de los problemas que la gente tiene con REST no son problemas con la arquitectura RESTful, sino con las implementaciones comunes. REST admite la negociación de contenido, es rico en funciones con todo lo que HTTP tiene para ofrecer y tiene soluciones básicas de prevención de búsqueda excesiva y insuficiente.

Básicamente, los problemas que Facebook se propuso solucionar son, a los ojos de muchas personas, problemas de implementaciones de REST deficientes y técnicas de codificación inadecuadas, no la arquitectura REST real en sí.

Independientemente del lado en el que caiga, básicamente se reduce a esto: ¿vale la pena el esfuerzo de adoptar GraphQL y Relay si se considera que muchas de sus características se pueden replicar de alguna manera en REST? ¿Cuáles son sus necesidades específicas? ¿Tiene datos de nivel (y estilo) de Facebook para administrar? De lo contrario, GraphQL y, por lo tanto, Relay, pueden no ser la mejor opción del mundo.

Conclusión

La retransmisión es poderosa, pero al igual que GraphQL, no es una fórmula mágica. Los datos de alto volumen en Relay son el estándar de oro para el manejo eficiente de datos, pero para el manejo de datos estándar, realmente debe preguntarse si es realmente mejor o no que el diseño RESTful adecuado.

Dicho esto, Relay aún está en su infancia. Proviene de Flux y, al igual que Flux, se repite constantemente y se expande en cosas más grandes y mejores. A medida que pase el tiempo, es probable que gran parte de la preocupación por Relay se mitigue, con su funcionalidad ampliada aún más mientras se hace más eficiente.

Publicar un comentario

0 Comentarios