Contenido del curso
Modelos y repositorios
Mensajes y eventos
Indexación mediante Elastic Search
Feed Service
Query Service y Pusher
Últimos pasos
CQRS: Command Query Responsibility Segregation
Sebastián Ospino
Estudiante
Dainer Acosta
EstudianteContenido del curso
CQRS: Command Query Responsibility Segregation
Sebastián Ospino
EstudianteDainer Acosta
Estudiante
Jeison Triana
Estudiante
José Antonio De La Paz Fonseca
Estudiante
Cristhian Arboleda
Estudiante
Elias Amado
Estudiante
Neo TRAN
Estudiante
Helmer Barcos
EstudianteHelmer Barcos
EstudianteHelmer Barcos
EstudianteLa tarea que se le asignó a NGINX no podría ser ejecutada por una API Gateway?
si, sin ningún problema
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?
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
¿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
osea en esta caso NGINX me esta trabajando haciendo las veces de cola pero es solo para el ejemplo verdad? En casos reales si se require desacoplar procesamiento si debemos tener una cola si o si.
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?
Si no estoy mal hay diferentes estrategias:
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.
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:
PublishAsync.📺 Playlist oficial de NATS JetStream:
📚 Más documentación: