Hacemos una verificación exhaustiva cada sección de nuestra página web con el objetivo de mostrarte siempre información veraz y actual.
Solución:
Definitivamente enfoque #1.
Hacer que sus clientes hablen con varios servicios de 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 su completo datos de la aplicación para permitir obtenerlos en un solo viaje de ida y vuelta.
Teniendo un no compartía nada arquitectura 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 todos de tus clientes Definitivamente te arrepentirás de eso.
GraphQL y los microservicios encajan perfectamente, porque GraphQL oculta a los clientes el hecho de que tiene una arquitectura de microservicios. Desde una perspectiva de back-end, desea dividir todo en microservicios, pero desde una perspectiva de front-end, 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 mismo tiempo que proporciona una única API para toda su aplicación y permite uniones entre datos de diferentes servicios.
Si no desea utilizar REST para sus microservicios, puede, por supuesto, 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 puertas de enlace API es para que sea más manejable llamar a microservicios desde aplicaciones cliente, no porque encaje bien en el patrón de microservicios.
Este artículo recomienda el enfoque #1. Vea también la siguiente imagen, tomada del artículo mencionado:
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 el avance 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 fundamentalmente puede ejercer un mayor control sobre el proceso de carga de datos. Debido a que el proceso para los cargadores de datos va a su propio punto final, puede cumplir con la solicitud de forma parcial, total o con advertencias y, por lo tanto, controlar de manera 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/
A mediados de 2019, la solución para el 1er enfoque ahora tiene el nombre de “Federación de esquemas” acuñado por la gente de Apollo (anteriormente, esto se conocía a menudo como unión GraphQL). También proponen los módulos @apollo/federation y @apollo/gateway para esto.
AGREGAR: tenga en cuenta que con Schema Federation no puede modificar el esquema en el nivel de la puerta de enlace. Entonces, por cada bit que necesita en su esquema, necesita tener un servicio separado.
Sección de Reseñas y Valoraciones
Si te ha resultado de ayuda nuestro artículo, sería de mucha ayuda si lo compartieras con otros seniors de esta forma nos ayudas a extender este contenido.