# Making a one-way rpc-like entrypoint

**URL:** <https://discourse.nameko.io/t/making-a-one-way-rpc-like-entrypoint/160>\
**Category:** googlegroup\
**Created:** [November 15, 2016, 12:34pm UTC](https://discourse.nameko.io/t/making-a-one-way-rpc-like-entrypoint/160 "2016-11-15T12:34:02Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [November 15, 2016, 12:34pm UTC](https://discourse.nameko.io/t/making-a-one-way-rpc-like-entrypoint/160/1 "2016-11-15T12:34:02Z")

</div>

Hi,

How can the "rpc" decorator (Rpc class) be tweaked in a way that it does not create a reply queue and send responses?  
Some of our service methods are one-way and we don't want/need the overhead of reply queues.

Thanks

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [November 15, 2016, 1:28pm UTC](https://discourse.nameko.io/t/making-a-one-way-rpc-like-entrypoint/160/2 "2016-11-15T13:28:55Z")

</div>

If you're doing service-to-service RPC there's really not much overhead in  
the reply queue -- it's created once and used for all replies to that  
service. You'd only be saving the publishing of the response.

It's also fairly easy to implement one-way messaging using the  
nameko.messaging.Publisher DependencyProvider and nameko.messaging.Consume  
Entrypoint. These give you pretty low-level access to AMQP, using whatever  
exchanges, queues and routing keys you like. I'd start with a subclass of  
these. You can then add RPC-style encoding of the payload into args and  
kwargs by lifting  
[https://github.com/nameko/nameko/blob/master/nameko/rpc.py#L372](https://github.com/nameko/nameko/blob/master/nameko/rpc.py#L372) and  
[https://github.com/nameko/nameko/blob/master/nameko/rpc.py#L158-L165\](https://github.com/nameko/nameko/blob/master/nameko/rpc.py#L158-L165%5C).

> **···**
>
> On Tuesday, November 15, 2016 at 12:34:02 PM UTC, tsachi...@gmail.com wrote:
> 
> > Hi,
> > 
> > How can the "rpc" decorator (Rpc class) be tweaked in a way that it does  
> > not create a reply queue and send responses?  
> > Some of our service methods are one-way and we don't want/need the  
> > overhead of reply queues.
> > 
> > Thanks

---

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [November 16, 2016, 12:15pm UTC](https://discourse.nameko.io/t/making-a-one-way-rpc-like-entrypoint/160/3 "2016-11-16T12:15:28Z")

</div>

Thanks Matt,

The use case is of clients using ClusterRpcProxy to send messages to a nameko cluster.  
Some types of messages don't require a response (send and forget), so I want to remove any unnecessary overheads, such as creating reply queues.

---

<div class="post-metadata">

**Author:** ![Tsachi\_Shuval](https://avatars.discourse-cdn.com/v4/letter/t/5e9695/32.png) [@Tsachi\_Shuval](https://discourse.nameko.io/u/Tsachi_Shuval)\
**Post date:** [February 9, 2017, 8:23am UTC](https://discourse.nameko.io/t/making-a-one-way-rpc-like-entrypoint/160/4 "2017-02-09T08:23:49Z")

</div>

To follow up with this topic, we are now experimenting with no-reply  
entrypoint.  
The way we implemented it is like this:

class NoReplyRpc(Rpc):  
&nbsp;&nbsp;&nbsp;def handle\_result(self, message, worker\_ctx, result, exc\_info):  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;self.rpc\_consumer.queue\_consumer.ack\_message(message)  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return result, exc\_info

no\_reply\_rpc = NoReplyRpc.decorator

Basically the change here is removing the rpc\_consumer call in  
handle\_result().

Client implementation uses a simple producer (from kombu) to push messages  
to the service queue, adding the correct routing key and empty 'reply\_to'  
and 'correlation\_id' keys.

Our tests look ok, but I'd like to hear your opinion too.  
Do you see any problem with such a solution?

---

<div class="post-metadata">

**Author:** ![mattbennett](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.nameko.io/mattbennett/32/13_2.png) [@mattbennett](https://discourse.nameko.io/u/mattbennett)\
**Post date:** [February 9, 2017, 11:36am UTC](https://discourse.nameko.io/t/making-a-one-way-rpc-like-entrypoint/160/5 "2017-02-09T11:36:15Z")

</div>

This looks like a fine implementation to me.

Nameko RPC essentially boils down to:

On the client side:

1) Create reply queue  
2) Publish a message containing the request to the service exchange...  
a) ... using routing key to identify the method  
b) ... setting reply-to to specify the queue to receive the reply  
c) ... setting correlation-id so the client can pipeline requests and  
identify the replies  
3) Consume messages from the reply-to queue, and map them back to requests  
using the correlation-id

On the server side:

1) Consume request messages from the service queue...  
a) ... fire the appropriate entrypoint according to the routing key  
2) Publish a message containing the response to the service exchange...  
a) ... using reply-to as the routing key so the response ends up in the  
correct queue  
b) ... setting correlation-id so the client can identify the replies  
3) ack the request message

For "no reply" RPC you drop 1, 2b, 2c and 3 on the client side, and 2a and  
2b on the server side. Which is exactly what your implementation does.

> **···**
>
> On Thursday, February 9, 2017 at 8:23:49 AM UTC, tsachi...@gmail.com wrote:
> 
> > To follow up with this topic, we are now experimenting with no-reply  
> > entrypoint.  
> > The way we implemented it is like this:
> > 
> > class NoReplyRpc(Rpc):  
> > &nbsp;&nbsp;&nbsp;def handle\_result(self, message, worker\_ctx, result, exc\_info):  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;self.rpc\_consumer.queue\_consumer.ack\_message(message)  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return result, exc\_info
> > 
> > no\_reply\_rpc = NoReplyRpc.decorator
> > 
> > Basically the change here is removing the rpc\_consumer call in  
> > handle\_result().
> > 
> > Client implementation uses a simple producer (from kombu) to push messages  
> > to the service queue, adding the correct routing key and empty 'reply\_to'  
> > and 'correlation\_id' keys.
> > 
> > Our tests look ok, but I'd like to hear your opinion too.  
> > Do you see any problem with such a solution?