CQRS: Command Query Responsibility Segregation

Clase 3 de 22 • Curso de Go Avanzado: Arquitectura de Eventos y CQRS

Sebastián Ospino

student•

La tarea que se le asignó a NGINX no podría ser ejecutada por una API Gateway?

Dainer Acosta

student•

si, sin ningún problema

Jeison Triana

student•

hay algo que no entiendo y es que si hay un evento para la lectura y otro para la escritura puedo inferir que son dos bds diferentes que ahora mi duda es como se puede controlar eso para mantener la bd de escritura sincronizada?

José Antonio De La Paz Fonseca

student•

Por el mismo sistema de eventos de publicador suscriptor de la clase pasada, aunque también se le añade algo de lógica para la sincronización entre evento de lectura y de escritura

Cristhian Arboleda

student•

¿Por qué el servicio de Query debe consultar los criterios de busqueda en Elastic y luego ir a buscar en la base de datos? Importante: Nunca he usado Elastic

Neo TRAN

student•

Si yo quisiera que algunos servicios estuvieran protegidos, que el usuario tenga que estar autenticado.

¿Lo tendría que validar NGINX llamando a algún servicio auth o desde cada microservicios usar el manejo de colas para comunicarse con auth por eventos y verificar al usuario?

Helmer Barcos

student•

Si no estoy mal hay diferentes estrategias:

La primera seria manejar auth & permissions en otro microservicio y este sea accedido desde todos los demás. Este siempre devuelve si hay acceso o no y también permisos. Seria una estrategia valida.
La segunda seria compartir un secret en todos los servicios. Este secret te ayudara a verificar la validez de tokens enviados via Authorization-Header. El problema aqui es que deberas buscar estrategias para sincronizar tokens inválidos o cuando se cambien contraseñas o permisos. lo cual me lleva a otra desventaja de esta estrategia: los permisos estarían atados al JWT y esta puede ser una lista muy larga y nunca completamente actualizada.
La tercera tener algo como OPA (open policy agent). No conozco mucho del tema pero se que es un proyecto graduado de la CNF y a lo mejor soluciona este problema con una estrategia mucho mas versátil y poderosa.

Helmer Barcos

student•

Durante dos semanas tuve una pregunta: ¿los datos estarán en dos lugares a la vez?

La respuesta corta es: ¡sí! De hecho, eso es algo deseado en este tipo de diseño. Pero, lamentablemente, este tema no se abordó en profundidad en el curso.

La respuesta larga se puede consultar en este enlace: 🔗

Básicamente, se entiende que el modelo de lectura y el modelo de escritura enfrentarán retos distintos con el tiempo. Por eso, se necesita una estrategia separada para cada uno y, al mismo tiempo, mantener los datos sincronizados.

Lo que aún me preocupa son los casos en que los eventos fallen o no puedan ser procesados, ya que eso significaría que el modelo de lectura quedaría desactualizado.

Helmer Barcos

student•

Luego de hacer una investigación exhaustiva, encontré que la forma en la que se abordó este curso está hoy en día deprecada. La recomendación actual es usar NATS JetStream (es decir, la imagen de Docker nats, no nats-streaming), la cual ademas resuelve los problemas relacionados a la entrega de los mensajes y la desconexión de alguna cliente.

Además, la nueva API de JetStream simplifica muchas de las tareas que antes debíamos manejar manualmente con channels. La nueva forma de trabajar se resume en:

Crear un Stream y configurarlo con una serie de subjects.
Publicar a través de ese stream a un subject específico usando PublishAsync.
En el indexador o servicio de consultas (query service), crear un Consumer, asignarle un nombre y procesar cada mensaje.

📺 Playlist oficial de NATS JetStream:

📚 Más documentación:

CQRS: Command Query Responsibility Segregation

Introducción

¿Qué estaremos construyendo en el curso?

Microservicios y arquitecturas basadas en eventos

CQRS: Command Query Responsibility Segregation

Modelos y repositorios

Creando modelos y repositorios

Implementando repositorio

Mensajes y eventos

Agregando NATS

Definiendo mensajes y eventos

Implementado interfaces para mensajes y eventos

Reaccionando a eventos

Indexación mediante Elastic Search

Agregando indexación

Implementando indexación mediante Elastic Search

Búsqueda mediante Elastic Search

Serialización de resultados de Elastic Search

Feed Service

Creando Feed Service

Creando Handlers para Feed Service

Agregando Feed Service como Command

Query Service y Pusher

Creando Query Service

Creando Handlers para Query Service

Creando el Servicio Pusher

Últimos pasos

Agregando NGINX

Probando nuestra aplicación de Feeds

Conclusiones