Header Ads Widget

Ticker

6/recent/ticker-posts

GraphQL: ¿Un modelo de datos para gobernarlos a todos?

Los datos tienen forma. La forma tiene significado. Los datos son una representación de la realidad objetiva. En su forma final, los datos están perfectamente normalizados y tienen 0 redundancia mientras se mantiene el 100% de integridad. Es un mundo ideal y hermoso creado por matemáticos e informáticos.


 

Y luego la realidad entra en acción. Dentro de su pila promedio, existen muchos modelos de datos en competencia para áreas como:

  • Almacenamiento (relacional o no)
  • Servicios de backend (Protobuf / gRPC) con protocolo REST
  • GraphQL (porque todos lo quieren)
  • Interfaz

Cada capa de la pila tiene un lenguaje único para definir objetos y relaciones. Estamos hablando de esquemas de base de datos, Protobufs y GraphQL SDL. Cada capa sigue sus propias funciones de optimización, tiene diferentes patrones de acceso y es mantenida por diferentes equipos.

Probablemente nadie "decidió activamente" tener todas esas capas en una sola pila. Técnicamente, no hay razón para mantener múltiples modelos de datos inconexos. Lo más probable es que sea el resultado de la evolución natural del software: agregar cada una de las capas tuvo sentido en algún momento.

En particular, la duplicación y la superposición se hacen evidentes si tiene protocolos back-end-to-back-end (microservicios) separados como Protobufs y luego protocolos back-end-to-front-end como GraphQL .

GraphQL fue creado para servidor-cliente para apaciguar los diseños de API centrados en el consumidor. En comparación con Protobuf, la especificación GraphQL proporciona soporte nativo para construir modelos de datos conectados a escala, como extensiones de tipo y delegación de esquema. Con un mejor formato de serialización y soporte para protocolos de transporte modernos, GraphQL también podría hacerse cargo de las comunicaciones servidor-servidor.

Modelo de datos desconectado para microservicios

Protobuf sobre gRPC: una configuración de backend popular.

La arquitectura de microservicios evolucionó para resolver problemas de velocidad de desarrollo backend al permitir implementaciones separadas, ejecución autónoma y propiedad clara. Protobuf sobre gRPC es quizás el protocolo más popular para implementar esta solución. Por eso, las mejores prácticas para la arquitectura de microservicios se centran en el desacoplamiento y la independencia.

Los modelos de datos a menudo se vuelven muy "desnormalizados" a medida que el problema de conectar tipos y obtener objetos reales por ID se incrementaron. Por ejemplo, es posible que el hecho de que la lista de ID de usuario en el mensaje de Equipo se pueda resolver en objetos de Usuario reales no esté integrado en el modelo de datos, sino que se distribuya en todos los lugares donde se use.

Modelo de datos único a escala

Logotipo de GraphQL

GraphQL: ¿Un protocolo más utilizable para la interfaz… y posiblemente toda la pila?

GraphQL se convirtió en la corriente principal un poco más tarde. Este protocolo trata de satisfacer las necesidades de los consumidores. El enfoque recomendado para definir el modelo de datos es mirarlo desde la perspectiva del cliente. Entonces, los tipos se vuelven a conectar en este nivel.

La comunidad alrededor de GraphQL es una multitud entusiasta (incluido yo mismo) y parece tener la ambición de hacerse cargo de las partes inferiores de la pila también. De hecho, proyectos como Prisma , Hasura y Postgraphile tienen como objetivo proporcionar directamente una API GraphQL para el acceso a la base de datos, eliminando la necesidad de una capa de backend tradicional en el medio.

Prisma v2 se ha convertido en una herramienta genérica de acceso a la interfaz javascript para DB sin un acoplamiento estrecho a GraphQL. Hasura y Postgraphile toman el esquema de la base de datos PostgreSQL y lo sirven a través de la interfaz GraphQL. Tienen enfoques muy diferentes sobre cómo se estructuran las implementaciones y ofrecen diferentes compensaciones, pero generalmente se basan en la misma idea de reutilizar el mismo modelo de datos en toda la pila.

Por supuesto, para una organización más grande, usar una sola base de datos para almacenar la totalidad de sus datos no es un enfoque viable. Entonces, la pregunta principal se refiere a las estrategias para fusionar y delegar partes de las consultas entre diferentes partes del sistema. Y ahí es donde GraphQL tiene el ecosistema más desarrollado, ya que permite de forma nativa la composición de API y las extensiones de tipo.

En proto3, no hay soporte "nativo" para tipos extendidos, y el enfoque recomendado es incluir cualquier blob de bytes, que depende de un consumidor para decodificar y codificar. Los tipos extendidos no son ciudadanos de primer nivel de la especificación.

Entonces, la tendencia para administrar modelos de datos más grandes es que las organizaciones que han adoptado los microservicios comienzan a agregar una capa GraphQL encima para normalizar el esquema y volver a conectar los tipos.

Desventajas de usar GraphQL para servidor-servidor

Entonces, ¿por qué te molestarías en mantener ambos (Protobuf y GraphQL)? Existen algunas desventajas de estandarizar en una sola solución (GraphQL) tanto para la comunicación de servidor a servidor como de servidor a front-end.

  • Falta de herramientas estándar : dado que GraphQL no es la primera opción para una arquitectura de microservicios, las herramientas y la infraestructura tradicionales, como el registro, la autenticación y el almacenamiento en caché, aún no se han estandarizado.
  • Rendimiento : la otra pregunta es si GraphQL puede tener el mismo rendimiento que Protobuf sobre gRPC. Creo que eventualmente puede, pero aún no está ahí. La serialización de datos predeterminada para la mayoría de las implementaciones de servidor GraphQL sigue siendo JSON, que es mucho más lento en comparación con Binary Protobuf. Además, gRPC se basa en HTTP2 , que es mucho más rápido que HTTP.

Si solo se comparan las dos tecnologías, al igual que JSON sobre HTTP (GraphQL) frente al formato binario sobre HTTP2 (Protobuf / gRPC), esta última siempre parecería una opción obvia.

Dicho esto, la especificación GraphQL no tiene ninguna recomendación sobre el protocolo de transferencia y el formato de serialización per se. De lejos, la comunidad en torno a GraphQL está principalmente orientada hacia clientes front-end. Por lo tanto, JSON sobre HTTP es una implementación muy lógica ya que todos los navegadores lo admiten. Sin embargo, la adaptación de estándares más avanzados (como HTTP 2/3 y BSON quizás) para GraphQL es solo cuestión de tiempo. Estos nuevos estándares podrían mejorar significativamente el rendimiento de GraphQL.

El modelo de datos futuro está más normalizado

GraphQL ha aislado correctamente las partes más defectuosas del proceso. A medida que la organización crece, la comunicación y la coordinación entre equipos se convierten en el cuello de botella. GraphQL ofrece un mejor terreno para facilitar la colaboración en equipo al pedir a los proveedores de datos que declaren sus capacidades (como un esquema publicable) y el enfoque de diseño de modelo de datos primero.

Además, hay algunas soluciones que ofrece la comunidad GraphQL para el problema de administrar modelos de datos conectados a escala. Una opción es la federación de Apollo y la unión de esquemas mediante herramientas graphql que nos permiten descentralizar la lógica y al mismo tiempo proporcionar una única API conectada.

Las organizaciones que deseen reducir la complejidad general del sistema mientras mantienen la flexibilidad asociada con la arquitectura de microservicios necesitarían conectarse y normalizar su modelo de datos subyacente.

Por lo tanto, las soluciones basadas en Protobuf adoptarán un enfoque de diseño de esquema curado y, por lo tanto, serán más amigables con los consumidores, o GraphQL se volverá más amigable para las necesidades de desarrollo de backend al adoptar protocolos de intercambio de datos más rápidos y avanzados.

 

Publicar un comentario

0 Comentarios