Arquitectura
ArquitecturaUsar componentes en lugar de grafos

Usar componentes en lugar de grafos

Gato GraphQL no utiliza grafos para representar el modelo de datos. En su lugar, utiliza componentes.

Este no es un enfoque inesperado. Bajo el título Thinking in Graphs, el proyecto GraphQL afirma (el énfasis es nuestro):

Los grafos son herramientas potentes para modelar muchos fenómenos del mundo real, porque se parecen a nuestros modelos mentales naturales y a las descripciones verbales del proceso subyacente. Con GraphQL, modelas tu dominio de negocio como un grafo definiendo un esquema; dentro de tu esquema, defines distintos tipos de nodos y cómo se conectan/relacionan entre sí. En el cliente, esto crea un patrón similar a la Programación Orientada a Objetos: tipos que referencian a otros tipos. En el servidor, dado que GraphQL solo define la interfaz, tienes la libertad de utilizarlo con cualquier backend (¡nuevo o heredado!).

La conclusión clave de esta definición es la siguiente:

Aunque la respuesta tenga forma de grafo, eso no significa que los datos estén realmente representados como un grafo al tratarlos en el lado del servidor. El grafo es solo un modelo mental, no una implementación real.

Esto son buenas noticias, porque trabajar con grafos (o árboles) no es trivial. Los componentes, en cambio, son mucho más sencillos de implementar y proporcionan exactamente las mismas ventajas.

Simplificando el modelo de datos mediante componentes

Utilizar componentes para representar la estructura de los datos en el lado del servidor es óptimo en términos de simplicidad, porque permite consolidar los distintos modelos para nuestros datos en una única estructura. En lugar de tener un flujo como este:

construir consulta para alimentar componentes (cliente) => procesar datos como grafo/árbol (servidor) => alimentar datos a los componentes (cliente)

...nuestro flujo será así:

componentes (cliente) => componentes (servidor) => componentes (cliente)

Esto es posible porque la solicitud GraphQL puede concebirse como una estructura de datos de "jerarquía de componentes", en la que cada tipo de objeto representa un componente, y cada campo relacional de un tipo de objeto a otro tipo de objeto representa un componente envolviendo a otro componente.

Usemos un ejemplo para visualizar esta relación entre componente y consulta GraphQL. Supongamos que queremos construir el siguiente widget "Director destacado":

Widget de director destacado

Usando Vue o React (o cualquier otra librería basada en componentes), primero identificaríamos los componentes. En este caso, tendríamos un componente exterior <FeaturedDirector> (en rojo), que envuelve un componente <Film> (en azul), que a su vez envuelve un componente <Actor> (en verde):

Identificación de los componentes en el widget

El pseudocódigo tendrá este aspecto:

<!-- Component: <FeaturedDirector> -->
<div>
  Country: {country}
  {foreach films as film}
    <Film film={film} />
  {/foreach}
</div>
 
<!-- Component: <Film> -->
<div>
  Title: {title}
  Pic: {thumbnail}
  {foreach actors as actor}
    <Actor actor={actor} />
  {/foreach}
</div>
 
<!-- Component: <Actor> -->
<div>
  Name: {name}
  Photo: {avatar}
</div>

A continuación, identificamos qué datos necesita cada componente. Para <FeaturedDirector> necesitamos name, avatar y country. Para <Film> necesitamos thumbnail y title. Y para <Actor> necesitamos name y avatar:

Identificación de las propiedades de datos para cada componente

Y construimos nuestra consulta GraphQL para obtener los datos requeridos:

query {
  featuredDirector {
    name
    country
    avatar
    films {
      title
      thumbnail
      actors {
        name
        avatar
      }
    }
  }
}

Como puede apreciarse, existe una relación directa entre la jerarquía de componentes anterior y esta consulta GraphQL.