Different configurations per endpoint

1

I have a situation where I need to connect to a second rabbitmq cluster that uses a slightly different rpc protocol than namekos. While the changes are quite small (mainly just different logic for the routing keys and a small change in the handling of body parameters), it’s quite hard to reuse the Extensions from “rpc”, so I ended up subclassing a lot of classes.
I might have been able to do this in a hackier way using some form of monkey patching, but there is a second Problem: I still need to connect to my “normal” nameko rabbitmq cluster (using the “normal” nameko protocol).

Given this combination of problems is probably pretty obscure, here’s a broader Question:

Is there a way to give a seperate configuration to a single dependency provider?


class MyService:
    name = 'my_service'
    service_a = RpcProxy('service_a')   # this is a service running in the standard nameko cluster 
    service_b = RpcProxy('service_b', override_config_somehow={'AMQP_URI': 'amqp://....', 'rpc_exchange': 'different-exchange'}
 
    @rpc 
    def process(self):
        data = service_b.do_something_in_different_cluster_or_exchange('test')
        service_a.use_data_in_normal_cluster(data)

Just wondering if there is an elegant solution for this? Actually, any solution would also be fine :slight_smile:.
The best I could come up with is to use a ClusterRpcProxy for one of them:


class MyService:
   name = 'my_service'

   service_a = RpcProxy('service_a')   # this is a service running in the standard nameko cluster 

   @rpc 
   def process(self):

       with ClusterRpcProxy({'AMQP_URI': 'amqp://....', 'rpc_exchange': 'different-exchange'}) as proxy:
           data = proxy.service_b.get_something_from_different_cluster_or_exchange('test')

       service_a.use_data_in_normal_cluster(data)

Of course, this would mean that in my original problem I would also have to recreate all of standalone.rpc as well.

As always, thank you for the great framework! It’s a joy to use (regardless of random edge cases like this one).

2

Hi Davis,

Thanks for the kind words and kudos for navigating your way around the RPC implementation. It is way harder than it should be to re-use any of it.

There are two changes in the works that will make it much easier to do that you’re trying to do there:

  1. Global config object (https://github.com/nameko/nameko/pull/520). This change decouples extensions from any pre-defined structure in the config file, so you’ll be free to read whatever part of the config that you need directly.

  2. Removing the queue consumer (https://github.com/nameko/nameko/pull/542). This branch massively simplifies the RPC implementation. It is approved but waiting for some pre-release testing before I’m happy to merge it to master.

1 Like