GraphQL y Arquitectura de Microservicios

Question

GraphQL y Arquitectura de Microservicios

Estoy tratando de entender dónde GraphQL es más adecuado para usar dentro de una arquitectura de Microservicios.

Existe cierto debate sobre tener solo 1 esquema GraphQL que funciona como API Gateway proxy de la solicitud a los microservicios de destino y coaccionar su respuesta. Los microservicios todavía usarían el protocolo REST / Thrift para el pensamiento de comunicación.

Otro enfoque es tener varios esquemas GraphQL uno por microservicio. Tener un servidor API Gateway más pequeño que dirija la solicitud al microservicio de destino con toda la información de la solicitud + la consulta GraphQL.

1ª aproximación

Tener 1 Esquema GraphQL como puerta de enlace de API tendrá un inconveniente en el que cada vez que cambie su contrato de microservicios de entrada/salida, tenemos que cambiar el Esquema GraphQL en consecuencia en el lado de Puerta de enlace de API.

2nd Approach

Si utiliza varios esquemas de GraphQL por microservicios, tenga sentido de alguna manera porque GraphQL impone una definición de esquema, y el consumidor tendrá que respetar la entrada / salida dada desde el microservicio.

Preguntas

¿Dónde encuentra GraphQL el ajuste adecuado para diseñar arquitectura de microservicios?
¿Cómo diseñaría una puerta de enlace API con una posible implementación de GraphQL?

88

architecture microservices graphql

Author: tom redfern, 2016-06-28

Source

5 answers

Vea el artículo aquí, que dice cómo y por qué el enfoque #1 funciona mejor. También mira la siguiente imagen tomada del artículo que mencioné:

Uno de los principales beneficios de tener todo detrás de un único endpoint es que los datos se pueden enrutar de manera más efectiva que si cada solicitud tuviera su propio servicio. Si bien este es el valor a menudo promocionado de GraphQL, una reducción en la complejidad y la fluencia del servicio, la estructura de datos resultante también permite que la propiedad de los datos sea extremadamente bien definido y claramente delineado.

Otro beneficio de adoptar GraphQL es el hecho de que puede afirmar fundamentalmente un mayor control sobre el proceso de carga de datos. Debido a que el proceso para los cargadores de datos entra en su propio punto final, puede honrar la solicitud parcial, completamente o con advertencias, y por lo tanto controlar de manera extremadamente granular cómo se transfieren los datos.

El siguiente artículo explica estos dos beneficios junto con otros muy bien: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices /

12

Author: Enayat Rajabi,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-07-24 16:31:13

Para el enfoque #2, de hecho, esa es la forma en que elijo, porque es mucho más fácil que mantener la molesta puerta de enlace de API manualmente. De esta manera puede desarrollar sus servicios de forma independiente. Hacer la vida mucho más fácil: P

Hay algunas herramientas excelentes para combinar esquemas en uno, por ejemplo, graphql-weaver y apollo graphql-tools, estoy usando graphql-weaver, es fácil de usar y funciona muy bien.

1

Author: HFX,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-03-05 06:52:48

Como la arquitectura de microservicios no tiene una definición adecuada, no hay un modelo específico para este estilo, pero la mayoría de ellos vendrán con pocos notables characteristics.In en el caso de la arquitectura de microservicios, cada servicio se puede dividir en pequeños componentes individuales, que se pueden ajustar e implementar individualmente sin afectar la integridad de la aplicación. Esto significa que simplemente puede cambiar algunos servicios sin tener que pasar por la redistribución de aplicaciones a través de custom microservicios desarrollo de aplicaciones.

0

Author: Demetrius Franco,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-12-03 05:52:55

Más sobre microservicios, creo que GraphQL también podría funcionar perfectamente en arquitectura sin servidor. No uso GraphQL pero tengo mi propio proyecto similar. Lo uso como un agregador que invoca y concentra muchas funciones en un solo resultado. Creo que podrías aplicar el mismo patrón para GraphQL.

-2

Author: Giap Nguyen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-08-23 08:32:49

score 144 · Accepted Answer

Definitivamente enfoque #1.

Hacer que sus clientes hablen con varios servicios de GraphQL (como en el enfoque #2) anula por completo el propósito de usar GraphQL en primer lugar, que es proporcionar un esquema sobre los datos de la aplicación para permitir recuperarlos en un solo viaje de ida y vuelta.

Tener una arquitectura shared nothing puede parecer razonable desde la perspectiva de los microservicios, pero para su código del lado del cliente es una pesadilla absoluta, porque cada vez que cambia uno de tus microservicios, tienes que actualizar todos de tus clientes. Definitivamente te arrepentirás de eso.

GraphQL y los microservicios encajan perfectamente, porque GraphQL oculta el hecho de que tiene una arquitectura de microservicios de los clientes. Desde una perspectiva de backend, desea dividir todo en microservicios, pero desde una perspectiva de frontend, desea que todos sus datos provengan de una sola API. El uso de GraphQL es la mejor manera que conozco que te permite hacer ambas cosas. Se le permite dividir su backend en microservicios, al tiempo que proporciona una única API a toda su aplicación y permite uniones entre datos de diferentes servicios.

Si no desea utilizar REST para sus microservicios, por supuesto, puede hacer que cada uno de ellos tenga su propia API GraphQL, pero aún debe tener una puerta de enlace de API. La razón por la que las personas usan puertas de enlace de API es para que sea más manejable llamar a microservicios desde aplicaciones cliente, no porque se ajuste bien a los microservicios patrón.