Header Ads Widget

Ticker

6/recent/ticker-posts

Revisión de Rejoiner

 Repasamos Rejoiner, una interesante herramienta de Google que genera un esquema GraphQL unificado para microservicios gRPC.

A medida que los microservicios se han vuelto más prominentes en el espacio de desarrollo web durante la última década, la forma en que cada microservicio se comunica con los microservicios relacionados se ha vuelto increíblemente importante. Si bien una única API monolítica tiene sus fallas, tiene la ventaja de permitir que todo exista dentro del mismo silo. La idea de tener una gran cantidad de microservicios, cada uno con sus advertencias y consideraciones únicas en la interacción, es potencialmente preocupante. Después de todo, los microservicios están destinados a mejorar la experiencia general, no a hacerla más complicada y difícil.

Este es un problema central en el espacio de microservicios. Entonces, ¿cómo resolvemos ese problema y qué hacemos para asegurarnos de resolverlo mientras brindamos extensibilidad y escalabilidad? A continuación, analizamos Rejoiner , una solución que aprovecha GraphQL. ¿Es una buena solución? Siga leyendo para averiguarlo.

¿Qué es Rejoiner?

Rejoiner: la solución no oficial de Google para unificar microservicios gRPC con el esquema GraphQL. Véalo en Github o  comience con los documentos .

La respuesta de Google al problema de la complejidad de los microservicios es aprovechar lo mejor de ambos mundos. Por un lado del argumento, un microservicio es mucho más escalable, extensible y eficiente que las alternativas monolíticas. Por otro lado, es esencialmente la fragmentación del servicio, que adolece de una complejidad adicional.

La solución no oficial de Google es Rejoiner , un método mediante el cual los microservicios (específicamente, microservicios gRPC) se pueden usar para generar el esquema GraphQL. Este esquema está diseñado para ser flexible, de fácil comprensión y fácil referencia. La idea, entonces, es que el esquema se puede usar para formar un tipo de API de fusión, una “interfaz de microservicios”, por así decirlo.

En la práctica, la capa Rejoiner GraphQL existe como una especie de capa de traducción. Si bien una interfaz puede tener cientos de microservicios detrás, la experiencia singular con esos microservicios se puede representar de manera efectiva como una experiencia API de interfaz singular debido al uso de GraphQL como mediador.

Sin embargo, Rejoiner no es solo una solución de capa de fusión. También cuenta con una flexibilidad impresionante en cómo se realiza esta traducción. Protobuf , un estándar abierto utilizado para serializar datos estructurados, se utiliza para definir tipos para obtener las definiciones de esquema. Estas definiciones se pueden editar con bastante eficacia utilizando el lenguaje específico de dominio (DSL) proporcionado.

Lo más importante es que los métodos para la obtención de datos se unen a través de anotaciones, lo que permite un manejo efectivo de las solicitudes utilizando la metodología GraphQL y el espíritu de diseño, al tiempo que presenta una metodología API de nivel superior singular y fácil de entender.

Funciones experimentales

Rejoiner no solo se contenta con hacer lo que hace actualmente, sin importar la eficacia con que lo haga. A partir de marzo de 2020, Rejoiner está investigando varias características experimentales. Quizás lo más interesante de ellos es el desarrollo de una función para que Rejoiner funcione a la inversa: el plan es "exponer cualquier esquema GraphQL como un servicio gRPC", que es lo contrario de su enfoque operativo actual. Esto agregaría una gran cantidad de extensibilidad a la solución y ayudaría en un rápido desarrollo, iteración y prueba.

Además, se planifica la compatibilidad con Relay y se planifica la compatibilidad con los tipos protoescalares de extremo a extremo sin pérdidas y una solución GraphQL Stream.

¿Cómo se usa Rejoiner?

Como ejemplo, podemos consultar la documentación de Rejoiner para saber cómo se puede crear una ventaja entre microservicios. En este ejemplo, ya hemos instalado Rejoiner y hemos agregado algunos tipos básicos en el esquema GraphQL / Rejoiner. Aquí, tenemos un tipo Todo que ejecuta alguna función en una API. Lo que queremos hacer es extraer los datos del usuario de otro microservicio en el esquema y enviar ese contenido para recuperar un correo electrónico.

final class TodoToUserSchemaModule extends SchemaModule {
  @SchemaModification(addField = "creator", onType = Todo.class)
  ListenableFuture<User> todoCreatorToUser(UserService userService, Todo todo) {
    return userService.getUserByEmail(todo.getCreatorEmail());
  }
}

Lo que esto hace es simplemente agregar una referencia al tipo "Usuario" en una API al tipo "Todo" en una segunda API. Al agregar esta referencia, hemos vinculado los dos tipos con una anotación que permite a Rejoiner comprender cómo manejar esa solicitud. Ahora, cuando solicitamos el correo electrónico y especificamos el usuario que se solicita, estos datos se pueden extraer de ambas API, unirlos y servirlos como una sola solicitud.

Ejemplo teórico

Si bien esto puede parecer una solicitud relativamente simple, podemos imaginar una mucho más complicada. Supongamos que estamos usando Rejoiner para atender solicitudes relacionadas con el comercio electrónico. Tenemos un escaparate que maneja pedidos y esos pedidos pueden incluir proveedores de envío, identificadores de cumplimiento del escaparate y, en última instancia, notificaciones a los clientes. En tal situación, tenemos cada aspecto de la experiencia total separado en API: el estado del pedido lo maneja un microservicio, los proveedores de envío otro y los identificadores de cumplimiento de la tienda otro.

El problema es que cada solicitud que hagamos no es simplemente una relación uno a uno. Es muy posible que un cliente tenga un solo pedido que se dirija a múltiples proveedores, y que estos múltiples proveedores necesiten consultar proveedores de envío que pueden ser únicos para cada envío individual.

En tal caso, usar una API tradicional no es una buena solución. Estaríamos viendo una sola solicitud de estado de pedido que realiza cinco, seis o más circuitos en toda la colección de microservicios, lo que agrega más tiempo y complejidad con cada pase. Con GraphQL y un servicio como Rejoiner, lo que podemos hacer es agregar tipos a cada uno de esos aspectos. El punto final del microservicio Pedidos puede tener tipos agregados, incluidos VendorID, StorefrontID, StatusID.

Cuando se proporciona un OrderID, el microservicio Pedidos responderá con el estado actual como conocido y almacenado en caché. Sin embargo, la interfaz de reenganche sabrá que el estado de cumplimiento del proveedor (VendorFul llenado) está alojado en la API de proveedores y, por lo tanto, utilizará la anotación adjunta para señalar que los datos del proveedor se manejan a través de esa API y no de pedidos. Si bien el resultado se puede unir al final del proceso a través de la API de la interfaz Rejoiner, cada elemento individual se puede enrutar y enviar al punto final apropiado dadas estas anotaciones.

Beneficios de reincorporación

Cabe señalar aquí que Rejoiner y GraphQL son dos soluciones distintas; muchos de los beneficios que hemos discutido aquí son principalmente beneficios de GraphQL con un beneficio adicional habilitado a través de la interfaz Rejoiner en el nivel superior. GraphQL es absolutamente utilizable por sí solo, lo que conlleva la pregunta: ¿por qué no usar GraphQL y evitar Rejoiner por completo?

GraphQL tiene muchos beneficios , pero en realidad está destinado a ser utilizado en un ámbito relativamente estrecho en términos de cantidad de servicios compatibles. El uso de GraphQL hace que todo sea posible para un solo microservicio, pero cuando todo está habilitado de esa manera en una multitud de API, eso puede ser un problema en términos de datos expuestos. Por lo tanto, GraphQL se usa generalmente en la API frontal, mientras que los microservicios subyacentes se definen más claramente e interactúan de una manera más estricta.

El uso de Rejoiner brinda una gran cantidad de oportunidades en términos de tratar los microservicios internos como si se enfrentaran al exterior. En otras palabras, la necesidad de controlar más estrictamente los datos internos entre microservicios individuales que deben usarse interoperablemente se reduce considerablemente cuando se usa un sistema anotado como Rejoiner. El impacto práctico de no tener que controlar todos y cada uno de los aspectos del ecosistema interno solo expone una mayor flexibilidad, asumiendo que la flexibilidad es necesaria y apropiada.

Contras potenciales

Si bien este enfoque tiene algunas ventajas claras, también hay algunos argumentos sólidos que se pueden presentar en contra del uso de Rejoiner en algunas aplicaciones. Parte del problema con Rejoiner es que se apoya mucho en GraphQL. La realidad de GraphQL , sin embargo, es que no todas las situaciones se van a beneficiar de su espíritu, paradigma de desarrollo, y el enfoque - de hecho, hay algunas situaciones que GraphQL puede hacer de forma activa más difícil.

Uno de los grandes costos de adoptar GraphQL es que necesariamente abre la base de datos a un costo teórico más alto por llamada. Cuando se puede diseñar una llamada para incluir la menor cantidad o la mayor cantidad de información posible, la base de datos debe diseñarse de manera que admita esto específicamente y permita que lo que quiera permitir sea llamado en su totalidad o en parte. Este costo se ve negado por los beneficios de GraphQL en la mayoría de las aplicaciones, pero en tales aplicaciones, lo principal que niega ese costo es el hecho de que los actores externos son fundamentalmente impredecibles. Si no puede predecir la interacción, permitir que el cliente que solicita dicha interacción controle su propia solicitud es una buena opción.

Sin embargo, los servicios internos son predecibles. Una infraestructura codificada correctamente debe tener un flujo de solicitudes que sea predecible y comprensible. Incluso si la solicitud final es quizás más grande de lo que pensó al principio, esa solicitud más grande necesariamente debe unir otros microservicios API, no permitir una cantidad infinita de datos. En la práctica, si una API solicita un conjunto de datos interno específico de un microservicio, debe ser esperado, conocido y cuantificable. Por lo tanto, el uso de GraphQL en tales situaciones (y, por lo tanto, el uso de Rejoiner) puede aumentar los costos de la base de datos sin ofrecer ningún valor real al usuario final.

También existe el hecho de que Rejoiner ofusca los microservicios internos hasta el punto de hacer que su API sea completamente ininteligible en el nivel básico. Si bien es cierto que hay casos en los que está bien hacer esto (y muchos en el ámbito de la seguridad argumentarían que esto es una ventaja, no una desventaja), en situaciones en las que necesita transparencia y apertura en el sistema, simplemente se ve obligado a hacerlo. invertir mucho esfuerzo en metadatos y comunicación contextual.

Conclusión

Como ocurre con la mayoría de las cosas en el espacio de la API, Rejoiner es una excelente opción para lo que hace, dado que lo que hace es muy específico, sin embargo, no es algo que pueda recomendarse ampliamente para todas las situaciones. En el mejor de los casos, Rejoiner eleva una red de microservicios a una mayor extensibilidad, usabilidad y potencial iterativo. Si se usa incorrectamente, podría resultar en una complejidad innecesaria tanto en la administración como en la operación. Dicho esto, si su caso de uso requiere sincronicidad interna entre microservicios que se enfrentan al público en una sola postura, Rejoiner es una excelente opción.

¿Qué opinas de Rejoiner? ¿Existen alternativas que quizás sirvan mejor para el caso de uso general? Háganos saber en los comentarios a continuación.

Publicar un comentario

0 Comentarios