"Loose coupling" is the keyword here, by having logical boundaries (not physical 🤭).
Год назад
Thank you for the correction. I meant to say physical boundaries for the microservices & API situations only. And yes, english gave up on me while recording 😅
really interesting, I've often not been to concerned about stopping modules from communicating with each other. The interface approach sounds logical, what are your thoughts on using events to have modules act depending on a fired event from another module?
Год назад+1
So, I don’t have a lot of experience with event-driven architectures. They’d definitely allow modules to have even less coupling, but there are some drawbacks IMO. First, I find it hard to keep up with events because they’re detached - it isn’t necessarily clear in the code where things are coming from/to. Secondly, AFAIK this approach usually leverages asynchronicity, so things are performed on the background. That leads to eventual consistency, which isn’t bad per se, but just another thing to be aware of. There are lots of benefits I can think of, such as fault tolerance, but I’m not too knowledgeable on the subject. I believe if you _know_ how to deal with it it can be a fantastic way to build applications. I know a few folks who talk about EDA on twitter - I can send them over to you if you’re interested :-)
I worked on this question before and concluded that modules replicate what composer packages do. If you also did this comparison, what led to the conclusion of modules? Of course, you might be referring to other languages in this video. I glue my packages together using glue code (instead of designing an API/interface), strictly speaking, the glue code is the interface, but it is usually more readable and less constrained
Год назад
I think you could most definitely extract them to packages, but if it refers to a single application I do not see a reason to - I think you lose a lot of context when you do that, and you also add some unnecessary complexity (handling packages, sharing common functionality, etc)
"Loose coupling" is the keyword here, by having logical boundaries (not physical 🤭).
Thank you for the correction. I meant to say physical boundaries for the microservices & API situations only.
And yes, english gave up on me while recording 😅
btw there is a humming sound in the background, but I don't think it was a bad connection in the audio equipment
probably the ac unit
really interesting, I've often not been to concerned about stopping modules from communicating with each other.
The interface approach sounds logical, what are your thoughts on using events to have modules act depending on a fired event from another module?
So, I don’t have a lot of experience with event-driven architectures.
They’d definitely allow modules to have even less coupling, but there are some drawbacks IMO.
First, I find it hard to keep up with events because they’re detached - it isn’t necessarily clear in the code where things are coming from/to.
Secondly, AFAIK this approach usually leverages asynchronicity, so things are performed on the background. That leads to eventual consistency, which isn’t bad per se, but just another thing to be aware of.
There are lots of benefits I can think of, such as fault tolerance, but I’m not too knowledgeable on the subject. I believe if you _know_ how to deal with it it can be a fantastic way to build applications. I know a few folks who talk about EDA on twitter - I can send them over to you if you’re interested :-)
I worked on this question before and concluded that modules replicate what composer packages do. If you also did this comparison, what led to the conclusion of modules? Of course, you might be referring to other languages in this video.
I glue my packages together using glue code (instead of designing an API/interface), strictly speaking, the glue code is the interface, but it is usually more readable and less constrained
I think you could most definitely extract them to packages, but if it refers to a single application I do not see a reason to - I think you lose a lot of context when you do that, and you also add some unnecessary complexity (handling packages, sharing common functionality, etc)
Can I Edit your RUclips video?
sure, hit me up on twitter