pattern for bff and architecture microservices graphql

architecture - for - express gateway graphql



GraphQL y arquitectura de microservicios (7)

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

Existe cierto debate acerca de tener solo 1 esquema GraphQL que funcione como API Gateway que envía la solicitud a los microservicios específicos y coacciona su respuesta. Los microservicios aún usarían el protocolo REST / Thrift para el pensamiento de comunicación.

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

1er enfoque

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

2º enfoque

Si usa el esquema de GraphQL múltiple por microservicios, tenga sentido de alguna manera porque GraphQL aplica una definición de esquema, y ​​el consumidor deberá respetar la entrada / salida del microservicio.

Preguntas

  • ¿Dónde encuentra GraphQL el adecuado para diseñar arquitectura de microservicios?

  • ¿Cómo diseñaría una API Gateway con una posible implementación de GraphQL?

Como la arquitectura de microservicios no tiene una definición adecuada, no existe un modelo específico para este estilo pero, la mayoría de ellos tendrá pocas características notables. En el caso de la arquitectura de microservicios, cada servicio se puede dividir en pequeños componentes individuales, que pueden ser ajustado e implementado individualmente sin afectar la integridad de la aplicación. Esto significa que simplemente puede cambiar algunos servicios sin tener que volver a implementar aplicaciones a través del desarrollo de aplicaciones de microservicios personalizados.

Definitivamente enfoque # 1.

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

Tener una arquitectura de nada compartido 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 sus microservicios, debe actualizar a todos sus clientes. Definitivamente te arrepentirás de eso.

GraphQL y los microservicios encajan perfectamente, porque GraphQL oculta el hecho de que tiene una arquitectura de microservicio de los clientes. Desde una perspectiva de back-end, desea dividir todo en microservicios, pero desde una perspectiva de interfaz, le gustaría que todos sus datos provengan de una sola API. Usar GraphQL es la mejor manera que conozco que te permite hacer ambas cosas. Le permite dividir su back-end en microservicios, al tiempo que proporciona una API única para todas sus aplicaciones y permite unir datos entre diferentes servicios.

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

He estado trabajando con GraphQL y microservicios

Según mi experiencia, lo que funciona para mí es una combinación de ambos enfoques, dependiendo de la funcionalidad / uso, nunca tendré una sola puerta de enlace como en el enfoque 1 ... pero no un gráfico para cada microservicio como enfoque 2.

Por ejemplo, basado en la imagen de la respuesta de Enayat, lo que haría en este caso es tener 3 puertas de enlace de gráficos (no 5 como en la imagen)

  • Aplicación (producto, cesta, envío, inventario, necesario / vinculado a otros servicios)

  • Pago

  • Usuario

De esta manera, debe prestar especial atención al diseño de los datos mínimos necesarios / vinculados expuestos de los servicios dependientes, como un token de autenticación, ID de usuario, ID de pago, estado de pago

En mi experiencia, por ejemplo, tengo la puerta de enlace "Usuario", en ese GraphQL tengo las consultas / mutaciones del usuario, iniciar sesión, iniciar sesión, cerrar sesión, cambiar contraseña, recuperar correo electrónico, confirmar correo electrónico, borrar cuenta, editar perfil, cargar imagen , etc ... este gráfico por sí solo es bastante grande !, está separado porque al final los otros servicios / puertas de enlace solo se preocupan por la información resultante, como ID de usuario, nombre o token.

De esta manera es más fácil ...

  • Escale / apague los diferentes nodos de puertas de enlace en función de su uso. (por ejemplo, es posible que las personas no siempre estén editando su perfil o pagando ... pero la búsqueda de productos podría usarse con mayor frecuencia).

  • Una vez que las puertas de enlace maduran, crecen, se conoce su uso o usted tiene más experiencia en el dominio, puede identificar cuáles son la parte del esquema que podría tener su propia puerta de enlace (... me ocurrió con un gran esquema que interactúa con los repositorios git , Separé la puerta de enlace que interactúa con un repositorio y vi que la única entrada necesaria / información vinculada era ... la ruta de la carpeta y la rama esperada)

  • La historia de sus repositorios es más clara y puede tener un repositorio / desarrollador / equipo dedicado a una puerta de enlace y sus microservicios involucrados.

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

Para el enfoque n. ° 2, de hecho, esa es la forma en que elijo, porque es mucho más fácil que mantener la molesta puerta de enlace 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 las graphql-tools de apollo, estoy usando graphql-weaver , es fácil de usar y funciona muy bien.

Vea el artículo here , que dice cómo y por qué el enfoque n. ° 1 funciona mejor. También mire la imagen a continuación tomada del artículo que mencioné:

Uno de los principales beneficios de tener todo detrás de un único punto final 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 esté extremadamente bien definida y claramente delineada.

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 cumplir con la solicitud de forma parcial, total o con advertencias, y así controlar de forma extremadamente granular cómo se transfieren los datos.

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