Descripción de diseño de servicios GraphQL
Esta página tiene como proposito el documentar y describir el razonamiento detrás del diseño de los servicios de datos en GraphQL dentro de CONABIO.
CONABIO como institución generadora de información tiene como uno de sus objetivos proporcionar información sobre biodiversidad para contribuir al entendimiento de los procesos biológicos que mantienen a los ecosistemas naturales. En este sentido uno de los principales requerimientos al diseñar una plataforma de publicación de sus datos debe considerar una salida homogénea para estos y de preferencia poder consultarlos desde un solo sitio, considerando las posibles relaciones de los mismos.
Para cumplir con este objetivo se consideró que crear un servicio GraphQL. Hay dos razones principales para haber elegido esta tecnología, la primera es que al tener un concepto de gráfica, en el sentido matemático, hace que las relaciones entre los tipos de datos sea mucho más explicito; la segunda razón es que al ser un lenguaje de consulta permite tener distintas proyecciones de los datos publicados esto hace que el diseño de los datos a publicar pueda centarse en qué atributos tienen que ser publicados y no en que datos necesita una aplicación, esto también repercute en la productividad de los equipos de desarrollo ya que se pueden concentrar los esfuerzos en el desarrollo de una sola aplicación.
Otra decisión en la propuesta del servicio de GraphQL fue la de que al mismo tiempo de tener una gráfica unificada de datos, que beneficia la inteconectividad de los datos, también se debía observar la modularidad del sistema (separation of concerns), es por esto que se optó por tener una federación de datos, esto es que la gráfica de datos es partida en subgráficas las cuales pueden ser desarrolladas de manera individual
Desarrollo de un servicio de datos GraphQL
Como final todo servicio de datos será integrado a la federación es importante tener presente que la información que se despliega corresponda solo a un contexto reducido de información la cual no se replique en otro sistema y pueda generar incosistencias de información. Por lo cual la primera decisión al momento de desarrollar un servicio es tener claro el alcance de los datos que serán íncluidos.
Al hacer este análisis se debe ver la unidad del dato así como sus características, con esto se ve cuales son los tipos de datos que serán implementados en el servicio de GraphQL. Además como otra decisión que se tomó es el uso de la especificación de federación propuesta por Apollo, esta implementación hace que las relaciones entre datos sean declarativas, por lo que en el servicio que se está desarrollando basta con definir la manera de identificar los datos expuestos y los servicios terceros no tendrán que saber la implementación especifica del servicio para referenciarlos si no solo conocer como referirse a ellos, esto generalmente se hace por medio de un identificador.
Teniendo las consideraciones anteriores ya solo queda la manera de recuperar los datos. Como se mencionó en https://ecoinformatica.atlassian.net/wiki/spaces/CONADATA/pages/302645296 cada dato debe tener un identificador único el cual sirve para recuperar el dato, es por eso que nuestro servicio debe observar la manera de recuperar un dato a partir de este identificador. Además también se debe poder resolver un conjunto de datos para eso debe tenerse una manera de indizar la información para que esta pueda ser devuelta aquí se decidió tener un índice en ElasticSearch el cual permite tener un sistema desacoplado de la base original para realizar las búsquedas y optimizado para hacerlas, en la figura se puede ver la arquitectura de los servicios.
La creación del índice de ElasticSearch es lo que modelará las preguntas que puede resolver el sistema de forma individual, ya que la resolución de las búsquedas se basa en los datos indexados dentro del índice. Es importante además de inidizar la información importante para cada registro también indizar los identificadores de los datos.
Referencias