[HN Gopher] Event Interception
       ___________________________________________________________________
        
       Event Interception
        
       Author : ingve
       Score  : 30 points
       Date   : 2024-03-05 15:49 UTC (7 hours ago)
        
 (HTM) web link (martinfowler.com)
 (TXT) w3m dump (martinfowler.com)
        
       | klabb3 wrote:
       | This makes sense but I can't really unsee the learnings from
       | subject based addressing in messaging systems like NATS. It would
       | make this article like one paragraph long.
       | 
       | The very idea that services should talk directly to another is
       | flawed even on happy days without any migrations and such.
       | There's service discovery, addressing, load balancing, firewall
       | configurations, rate limiting that really should all be part of
       | one logical connectivity plane. In NATS, your services can run
       | behind a residential NAT if you wanted to, all you need is to
       | connect to the cluster and choose a subject space.
       | 
       | Reverse proxies is probably the most common modern solution
       | though in things like k8s. I'm not wise enough to say if they are
       | better from an architectural pov.
        
         | jjtheblunt wrote:
         | agreed; you made me realize something i'd not connected before:
         | NATS has a bit of similarity to Linda Tuplespaces and I think
         | Javaspaces, when i think about its addressing.
        
         | ericyd wrote:
         | thanks, you made me realize I know nothing about anything
        
           | marktani wrote:
           | thanks, you made me realize I'm not alone
        
         | peter_l_downs wrote:
         | Is this the NATS you're referring to here? Forgive the noob
         | question, I just haven't come across that acronym before
         | (except in the Network Address Translation context.)
         | https://nats.io/
        
       | tester756 wrote:
       | >As we look to displace a legacy system a part at a time, we look
       | to identify, extract and replace application capabilities. To do
       | this we will be introducing cases where both the legacy system
       | and its replacement need to interact - be that to handle state
       | changes, processing of commands, queries or user interactions.
       | Often the legacy system is difficult or costly to change
       | (addressing this challenge may be the primary reason for the
       | displacement programme in the first place), and so we need a
       | mechanism that can allow new capabilities provided by the new
       | systems to be integrated, whilst minimising impacts to the legacy
       | system.
       | 
       | How is this different from Anti-corruption Layer pattern
       | https://learn.microsoft.com/en-us/azure/architecture/pattern...
       | 
       | >Implement a facade or adapter layer between different subsystems
       | that don't share the same semantics. This layer translates
       | requests that one subsystem makes to the other subsystem.
       | 
       | It feels like those are very very close or almost the same
       | concepts.
       | 
       | Or that can achieve the same results.
        
       ___________________________________________________________________
       (page generated 2024-03-05 23:00 UTC)