4 ms·
That's fair enough if you use something that actually does this and also keeps track of users of your event. Not saying it is unsolvable. What I've seen though
by tharkun__ 3y ago
That's fair enough if you use something that actually does this and also keeps track of users of your event. Not saying it is unsolvable.
What I've seen though is that in many cases it is unsolved for and it's very hard to reason about "if I remove this event because it's 5 versions too old already and I don't want to keep this backwards compatibility layer, will something "at the other end of our system I never even interact with" puke?
Granted some orgs are so big that it makes sense to solve for these large landscapes of services with backwards compatibility ad absurdum in order to allow anything to get done (been at that bank, done that). But reason about the entire system it does not make easier.
At many smaller orgs these services were also not built because of organizational issues that needed to be solved but because "everyone does this now" and there's no proper registry of properly defined interfaces and trying to find out if a change you were going to make is going to take you forever because you do need to version something or if you can just change things as needed is way harder than it's supposed to be at that size org.
- emodendroket 3y agoIt's freeing you to reason about only one step rather than the entire system at all times.
- tharkun__ 3y agoFair enough that it's freeing overall if your org is so large that it is faster to always be 100% backwards compatible for aeons. I repeat: most orgs that go all in on this are actually so small that being so compatible is more of a drag than understanding the part of the system that is attached to the interface you are trying to change ;)
- emodendroket 3y agoWell that's what I mean about choosing the right events. If you are needing to keep multiple systems in your head all the time the boundaries are wrong. But it's true that evolving the interface of services is hard.