A very clean solution, but I got some questions. How do you solve eventual consistency? What happens if the second command of the saga fails, how do you roll back?
CQRS systems are by design eventually consistent, since where you write is not where you read, it will take some time until the update propagates to the read side. There is nothing you can do about that. For the rollback, you can have rollback commands like `UserCreationFailedCommand` that you execute from the saga, to undo a previous modification
Man, it really would have been great if he explained in the beginning that this will be a talk about event-driven microservice architectures (CQRS). As someone who hasn't worked with microservices before, I was quite lost during the talk constantly asking myself - why this was outside the paradigms I am familiar with.
CQRS offers a type of decoupling (commands vs. queries) often paired with event-sourced systems which themselves work well with the async nature of microservices, but those three things are not one and the same. You can definitely have a CQRS system that uses a monolithic architecture.
@@kamilmysliwiec7394 in the documentation it says that "Commands can be dispatched from the services or directly from the controllers" but here you said that no needs for services so which approach is better?
My english is not good and he speaks so fast, but it is amazing - I clearly understand absolutely everything. Thank you! Nestjs rocks!
Согласен)
Powerful! The boss of NestJS
How guys build such fucking awesome framework by their own while doing day to day job.
A mystery indeed
he is crazy
Impressive, time to concentrate more on the benefits of using nestjs.
Love u man .. you cleared my doubts on cqrs .. thanks 👏👏👏👍👍👍🎁🎸🎸🇮🇳
Thank you for accessible of translation Sign Language
A very clean solution, but I got some questions.
How do you solve eventual consistency? What happens if the second command of the saga fails, how do you roll back?
This is a conference talk. we dont talk about fail cases. LOL
You can use an interceptor to start a a db transaction catch an error rollback. dev.to/teamhive/creating-a-transaction-interceptor-using-nest-js-2inb
CQRS systems are by design eventually consistent, since where you write is not where you read, it will take some time until the update propagates to the read side. There is nothing you can do about that. For the rollback, you can have rollback commands like `UserCreationFailedCommand` that you execute from the saga, to undo a previous modification
Man, it really would have been great if he explained in the beginning that this will be a talk about event-driven microservice architectures (CQRS). As someone who hasn't worked with microservices before, I was quite lost during the talk constantly asking myself - why this was outside the paradigms I am familiar with.
CQRS has absolutely nothing to do with microservices.
CQRS offers a type of decoupling (commands vs. queries) often paired with event-sourced systems which themselves work well with the async nature of microservices, but those three things are not one and the same. You can definitely have a CQRS system that uses a monolithic architecture.
nestjs rocks
Wanna see 4 hours version with all details
better everytime : )
Where in this approach a Queries?
Here you can find more on queries with this event-driven microservice architecture approach docs.nestjs.com/recipes/cqrs#queries
14:29 look at the translation guy at the bottom :D
Redux is the best tool to describe bad Developer Experience
Where do I find this stuff in the documentation? I must be blind ...
See here docs.nestjs.com/recipes/cqrs
github.com/kamilmysliwiec/nest-cqrs-example
@@kamilmysliwiec7394 in the documentation it says that "Commands can be dispatched from the services or directly from the controllers" but here you said that no needs for services so which approach is better?
@@eugenea7637 hi, do you know where i can find query example.
Didn't really understood the decorators :C
You can find more on decorators here: docs.nestjs.com/custom-decorators
Thanks! This is great stuff, but someone needs to tell Kamil it's pronounced "evEnt" :)
i feel like if node.js is going to be as complex as .net core then i will just stick with .net core lol