Listening to Udi is always both a pleasure and a great education. To explain a complex thing in simple words as a coherent story requires lots of knowledge and experience. Thanks for sharing. Like always, it was legen… wait for it… dary. Legendary 😀
Spoiler: the trick is to generate a client side ID for your entities. With all due respect to Udi, I'm kinda disappointed by this talk. I expected something about managing coupling in complex systems, but this turned out to be about a specific solution to a specific problem.
Important note, that if you're "packaging" all the data into 1 request, which will be split and sent to different services later on, then your business might lose important metrics, for example, when order is placed, but shipping (or anything else) information was not provided. Cause order is placed as a whole or not at all. If I were a business, I'd want to know why and where is the problem. You can still achieve somewhat the same result with stream processing (aggregation, ksql, whatever) and collect important metrics. Or am I missing something?
Calling separate service APIs from micro-frontends carries risk of compromising order integrity. If any of the network calls fails, it will leave the backend order in an inconsistent state. For any revenue generating system like two examples mentioned, it is not a risk worth taking, IMHO. Do the trade-off analysis before implementing the de-coupling at UI layer. Tx
Have you really decoupled your system if every part of your system must use the same unique ID for a given entity? Sure, if you remove your FKs and move data to a different database, you won't find an arrow in your DB diagram linking two entities together, but there is still logical coupling between them. Now you have introduced more complexity to handle your business logic. Is it worth it? Maybe, depending on the complexity of your product and organization. Building any sufficiently complex distributed system is hard, so do it only when there are clear advantages present in your concrete situation.
@@01110100011101110110 coupling is nothing more than a measure of effort required to make a change. Just because two services use the same ID doesn't mean that there is a coupling. Furthermore, there will always be SOME coupling. The only real decoupling is if two systems don't interact with each other at all, and that's not the case with systems serving the same business domain. Here, "decoupling" by using the same UUID means that one service can update its internal workings, and indeed its database schema or technology, without affecting other services. Each service also holds its own subset of data about a particular entity, the only thing having in common being the entity's ID.
My user clicks on a button in a screen. Please tell me how Pub/Sub could work with it without transforming an interaction based flow into a subscription based, without "increasing complexity".
Vertical slices, data ownership, encapsulation. th-cam.com/video/PEKxP8DqEt4/w-d-xo.html. Yeah, really. Udi is the only one who is actually serious about it.
Please dont waste your time like me. his trick is that if you want to manage decoupled data at different parts, create corelating ID upfront before record is created and use it for parallel functions for coupling where needed. This is first NDC Conference video i found so bad and got tricked into watching it.
I don't think this comment does justice. Pretty much everything can be summarised like that. Even books- "not worth reading, here are the bullet points with key takeaways". The point about such presentations is the additional context.
The sales component is totally decoupled. An item is an item and it has a price. Until you start selling services, whose price may be based on a rate and a duration, and the duration may not be known up front. Or the rate may change over time. In the real world business rules are not as decoupled as this presentation assumes.
Fr, this literally happened to me last week. I booked a hotel for August 3rd in may and got charged ~1.2x the price and only found out when I was checking in
Listening to Udi is always both a pleasure and a great education. To explain a complex thing in simple words as a coherent story requires lots of knowledge and experience. Thanks for sharing. Like always, it was legen… wait for it… dary. Legendary 😀
What a great speaker, thank you.
Udi is a fantastic speaker and this is a great talk and it has been featured in the last issue of Tech Talks Weekly newsletter 🎉
Congrats!
Thanks
Spoiler: the trick is to generate a client side ID for your entities.
With all due respect to Udi, I'm kinda disappointed by this talk. I expected something about managing coupling in complex systems, but this turned out to be about a specific solution to a specific problem.
Great talk for a great speaker... I can rallly! recoment his 5 days class.. Absolutly worth the time and money
Important note, that if you're "packaging" all the data into 1 request, which will be split and sent to different services later on, then your business might lose important metrics, for example, when order is placed, but shipping (or anything else) information was not provided. Cause order is placed as a whole or not at all. If I were a business, I'd want to know why and where is the problem.
You can still achieve somewhat the same result with stream processing (aggregation, ksql, whatever) and collect important metrics.
Or am I missing something?
Calling separate service APIs from micro-frontends carries risk of compromising order integrity. If any of the network calls fails, it will leave the backend order in an inconsistent state. For any revenue generating system like two examples mentioned, it is not a risk worth taking, IMHO. Do the trade-off analysis before implementing the de-coupling at UI layer. Tx
the shape of data is just as much a constraint as the behavior
Have you really decoupled your system if every part of your system must use the same unique ID for a given entity? Sure, if you remove your FKs and move data to a different database, you won't find an arrow in your DB diagram linking two entities together, but there is still logical coupling between them. Now you have introduced more complexity to handle your business logic. Is it worth it? Maybe, depending on the complexity of your product and organization. Building any sufficiently complex distributed system is hard, so do it only when there are clear advantages present in your concrete situation.
@@01110100011101110110 coupling is nothing more than a measure of effort required to make a change. Just because two services use the same ID doesn't mean that there is a coupling. Furthermore, there will always be SOME coupling. The only real decoupling is if two systems don't interact with each other at all, and that's not the case with systems serving the same business domain.
Here, "decoupling" by using the same UUID means that one service can update its internal workings, and indeed its database schema or technology, without affecting other services. Each service also holds its own subset of data about a particular entity, the only thing having in common being the entity's ID.
I wish I knew this trick earlier. 😊
Bro I never thought nothing even close. I oye this guy 500 dollars minimun.
My user clicks on a button in a screen. Please tell me how Pub/Sub could work with it without transforming an interaction based flow into a subscription based, without "increasing complexity".
are you dense or just graduated from wordpress uni? how do u think web api’s work?
@@trejohnson7677 A little agressive, no?
Vertical slices, data ownership, encapsulation. th-cam.com/video/PEKxP8DqEt4/w-d-xo.html. Yeah, really. Udi is the only one who is actually serious about it.
introducing, graphql subscriptions!
This is hilarious. Spoiler the trick is in his name!
Clue: 🙃
UUID Dahan :D
At 42:00 😅
Please dont waste your time like me. his trick is that if you want to manage decoupled data at different parts, create corelating ID upfront before record is created and use it for parallel functions for coupling where needed. This is first NDC Conference video i found so bad and got tricked into watching it.
Thanks man saving my time:)
I don't think this comment does justice. Pretty much everything can be summarised like that. Even books- "not worth reading, here are the bullet points with key takeaways". The point about such presentations is the additional context.
Bless you my guy
The sales component is totally decoupled. An item is an item and it has a price.
Until you start selling services, whose price may be based on a rate and a duration, and the duration may not be known up front. Or the rate may change over time.
In the real world business rules are not as decoupled as this presentation assumes.
28:25 DAL
"you cannot show one price and charge another price". What planet is he from ? :D
Fr, this literally happened to me last week. I booked a hotel for August 3rd in may and got charged ~1.2x the price and only found out when I was checking in
Why the "clickbait" title for a tech talk? It's not even funny. People interested in these topics need to invest their time wisely.
resume-driben development, that's how average works, they come in packs.