New blog post: Microservices with Python, RabbitMQ and Nameko

Bruno_Rocha · March 5, 2016, 12:02am

Microservices with Python, RabbitMQ and Nameko

mattbennett · March 6, 2016, 1:20pm

Nice!

Did you consider using a nameko service for the "API" component? (Using the
@http entrypoint)

It would be amazing if there was a flasgger equivalent for nameko

···

On Saturday, March 5, 2016 at 12:02:25 AM UTC, Bruno Rocha wrote:

Microservices with Python, RabbitMQ and Nameko

http://brunorocha.org/python/microservices-with-python-rabbitmq-and-nameko.html

Remco_Boerma · March 10, 2016, 2:28pm

Nice article!

You use .async() of rpc but don't care about the results. I have 2
questions about that:

1) isn't it creating a lot of overhead if you would send messages this
way? (return queue preparation and all that)
2) what happens with the result anyway? Do you end up with a stuffed
rabbit? dead letters?

Thanks!

···

Op zaterdag 5 maart 2016 01:02:25 UTC+1 schreef Bruno Rocha:

Microservices with Python, RabbitMQ and Nameko

http://brunorocha.org/python/microservices-with-python-rabbitmq-and-nameko.html

7ooony · May 9, 2016, 10:18am

I get the same YagAddressError as the commenter on your article Vihar Popat:

Traceback (most recent call last):

File "<console>", line 1, in <module>

File
"/home/centos/projects/service-mail/service_env/lib/python2.7/site-packages/nameko/
rpc.py", line 351, in __call__

return reply.result()

File
"/home/centos/projects/service-mail/service_env/lib/python2.7/site-packages/nameko/
rpc.py", line 337, in result

raise deserialize(error)

RemoteError: YagAddressError

···

-----------
This happens only when using nameko, otherwise Yagmail works fine. So it's
a problem with nameko's data serialization? Does anyone know what's going
on?

On Saturday, March 5, 2016 at 7:02:25 AM UTC+7, Bruno Rocha wrote:

Microservices with Python, RabbitMQ and Nameko

http://brunorocha.org/python/microservices-with-python-rabbitmq-and-nameko.html

Bruno_Rocha · March 7, 2016, 5:49pm

I did not tried Nameko http yet. But I will take a look and try to develop
a port of Flasgger (Swaggeko?)

Does Nameko http uses werkzeug routing Rules? if so, it is easy to port.

···

On Sun, Mar 6, 2016 at 10:20 AM, Matt Bennett <bennett.matthew@gmail.com> wrote:

Nice!

Did you consider using a nameko service for the "API" component? (Using
the @http entrypoint)

It would be amazing if there was a flasgger equivalent for nameko

On Saturday, March 5, 2016 at 12:02:25 AM UTC, Bruno Rocha wrote:

Microservices with Python, RabbitMQ and Nameko

http://brunorocha.org/python/microservices-with-python-rabbitmq-and-nameko.html

--
You received this message because you are subscribed to a topic in the
Google Groups "nameko-dev" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/nameko-dev/QijBX_DMsJ8/unsubscribe\.
To unsubscribe from this group and all its topics, send an email to
nameko-dev+unsubscribe@googlegroups.com.
To post to this group, send email to nameko-dev@googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/nameko-dev/222ba4ed-5a86-4801-843c-ed8a11e0d512%40googlegroups.com
<https://groups.google.com/d/msgid/nameko-dev/222ba4ed-5a86-4801-843c-ed8a11e0d512%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout\.

--

*Bruno Rocha - @rochacbruno <http://twitter.com/rochacbruno>\*
http://brunorocha.org
rochacbruno (Bruno Rocha) · GitHub
http://linkedin.com/in/rochacbruno
Google Workspace Updates: New community features for Google Chat and an update on Currents <Google Workspace Updates: New community features for Google Chat and an update on Currents;

Bruno_Rocha · March 10, 2016, 2:50pm

1) isn't it creating a lot of overhead if you would send messages this
way? (return queue preparation and all that)

In the case of email sending I don't care about the results
immediately, the caller will get the results in the email body after. I
don't know if async has overheads.

2) what happens with the result anyway? Do you end up with a stuffed
rabbit? dead letters?

Since the "consumer/worker" finished the task it sends "ack" signal to
rabbit. I don't think there is "dead letters" after that, even if the
consumer fails, messages has an TTL there.

···

--

*Bruno Rocha - @rochacbruno <http://twitter.com/rochacbruno>\*
http://brunorocha.org
rochacbruno (Bruno Rocha) · GitHub
http://linkedin.com/in/rochacbruno
Google Workspace Updates: New community features for Google Chat and an update on Currents <Google Workspace Updates: New community features for Google Chat and an update on Currents;

Bruno_Rocha · July 19, 2016, 2:39am

I updated the post and example code available
here: GitHub - rochacbruno/nameko-example: Code for example in this post: http://brunorocha.org/python/microservices-with-python-rabbitmq-and-nameko.html (suggestions and PRs
are welcome)

···

On Monday, May 9, 2016 at 7:18:21 AM UTC-3, 7oo...@gmail.com wrote:

I get the same YagAddressError as the commenter on your article Vihar
Popat:

Traceback (most recent call last):

File "<console>", line 1, in <module>

File
"/home/centos/projects/service-mail/service_env/lib/python2.7/site-packages/nameko/
rpc.py", line 351, in __call__

return reply.result()

File
"/home/centos/projects/service-mail/service_env/lib/python2.7/site-packages/nameko/
rpc.py", line 337, in result

raise deserialize(error)

RemoteError: YagAddressError

-----------
This happens only when using nameko, otherwise Yagmail works fine. So it's
a problem with nameko's data serialization? Does anyone know what's going
on?

On Saturday, March 5, 2016 at 7:02:25 AM UTC+7, Bruno Rocha wrote:

Microservices with Python, RabbitMQ and Nameko

http://brunorocha.org/python/microservices-with-python-rabbitmq-and-nameko.html

David_Szotten · March 7, 2016, 6:03pm

Yep, nameko http is built on top of werkzeug, just like flask. Rules:

github.com

nameko/nameko/blob/master/nameko/web/handlers.py#L25


      
          
          
          class HttpRequestHandler(Entrypoint):
              server = WebServer()
          
              def __init__(self, method, url, **kwargs):
                  self.method = method
                  self.url = url
                  super(HttpRequestHandler, self).__init__(**kwargs)
          
              def get_url_rule(self):
                  return Rule(self.url, methods=self.method.split(','))
          
              def setup(self):
                  self.server.register_provider(self)
          
              def stop(self):
                  self.server.unregister_provider(self)
                  super(HttpRequestHandler, self).stop()
          
              def get_entrypoint_parameters(self, request):

David

···

On Monday, 7 March 2016 17:49:37 UTC, Bruno Rocha wrote:

I did not tried Nameko http yet. But I will take a look and try to develop
a port of Flasgger (Swaggeko?)

Does Nameko http uses werkzeug routing Rules? if so, it is easy to port.

On Sun, Mar 6, 2016 at 10:20 AM, Matt Bennett <bennett...@gmail.com > <javascript:>> wrote:

Nice!

Did you consider using a nameko service for the "API" component? (Using
the @http entrypoint)

It would be amazing if there was a flasgger equivalent for nameko

On Saturday, March 5, 2016 at 12:02:25 AM UTC, Bruno Rocha wrote:

Microservices with Python, RabbitMQ and Nameko

http://brunorocha.org/python/microservices-with-python-rabbitmq-and-nameko.html

--
You received this message because you are subscribed to a topic in the
Google Groups "nameko-dev" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/nameko-dev/QijBX_DMsJ8/unsubscribe\.
To unsubscribe from this group and all its topics, send an email to
nameko-dev+...@googlegroups.com <javascript:>.
To post to this group, send email to namek...@googlegroups.com
<javascript:>.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/nameko-dev/222ba4ed-5a86-4801-843c-ed8a11e0d512%40googlegroups.com
<https://groups.google.com/d/msgid/nameko-dev/222ba4ed-5a86-4801-843c-ed8a11e0d512%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout\.

--

*Bruno Rocha - @rochacbruno <http://twitter.com/rochacbruno>\*
http://brunorocha.org
rochacbruno (Bruno Rocha) · GitHub
http://linkedin.com/in/rochacbruno
Google Workspace Updates: New community features for Google Chat and an update on Currents <Google Workspace Updates: New community features for Google Chat and an update on Currents;

David_Szotten · March 10, 2016, 3:14pm

async without waiting:

the service container will still receive the reply, but discard it

···

On Thursday, 10 March 2016 14:50:32 UTC, Bruno Rocha wrote:

1) isn't it creating a lot of overhead if you would send messages this

way? (return queue preparation and all that)

In the case of email sending I don't care about the results
immediately, the caller will get the results in the email body after. I
don't know if async has overheads.

2) what happens with the result anyway? Do you end up with a stuffed
rabbit? dead letters?

Since the "consumer/worker" finished the task it sends "ack" signal to
rabbit. I don't think there is "dead letters" after that, even if the
consumer fails, messages has an TTL there.

--

*Bruno Rocha - @rochacbruno <http://twitter.com/rochacbruno>\*
http://brunorocha.org
rochacbruno (Bruno Rocha) · GitHub
http://linkedin.com/in/rochacbruno
Google Workspace Updates: New community features for Google Chat and an update on Currents <Google Workspace Updates: New community features for Google Chat and an update on Currents;

Remco_Boerma · March 10, 2016, 4:00pm

Thanks Bruno, David for clearing that up.

David, do you know if there is much overhead in setting up the response
queues and such?

···

Op donderdag 10 maart 2016 16:14:07 UTC+1 schreef David Szotten:

async without waiting:

the service container will still receive the reply, but discard it

On Thursday, 10 March 2016 14:50:32 UTC, Bruno Rocha wrote:

1) isn't it creating a lot of overhead if you would send messages this

way? (return queue preparation and all that)

In the case of email sending I don't care about the results
immediately, the caller will get the results in the email body after. I
don't know if async has overheads.

2) what happens with the result anyway? Do you end up with a stuffed
rabbit? dead letters?

Since the "consumer/worker" finished the task it sends "ack" signal to
rabbit. I don't think there is "dead letters" after that, even if the
consumer fails, messages has an TTL there.

--

*Bruno Rocha - @rochacbruno <http://twitter.com/rochacbruno>\*
http://brunorocha.org
rochacbruno (Bruno Rocha) · GitHub
http://linkedin.com/in/rochacbruno
Google Workspace Updates: New community features for Google Chat and an update on Currents
<Google Workspace Updates: New community features for Google Chat and an update on Currents;

David_Szotten · March 10, 2016, 5:34pm

the reply queue in rabbit is only set up once for the whole container.
there will be some small amount of overhead in actually sending and
receiving the replies, but i've not got any measurements i'm afraid

d

···

On Thursday, 10 March 2016 16:00:47 UTC, remco....@gmail.com wrote:

Thanks Bruno, David for clearing that up.

David, do you know if there is much overhead in setting up the response
queues and such?

Op donderdag 10 maart 2016 16:14:07 UTC+1 schreef David Szotten:

async without waiting:

the service container will still receive the reply, but discard it

On Thursday, 10 March 2016 14:50:32 UTC, Bruno Rocha wrote:

1) isn't it creating a lot of overhead if you would send messages this

way? (return queue preparation and all that)

In the case of email sending I don't care about the results
immediately, the caller will get the results in the email body after. I
don't know if async has overheads.

2) what happens with the result anyway? Do you end up with a stuffed
rabbit? dead letters?

Since the "consumer/worker" finished the task it sends "ack" signal
to rabbit. I don't think there is "dead letters" after that, even if the
consumer fails, messages has an TTL there.

--

*Bruno Rocha - @rochacbruno <http://twitter.com/rochacbruno>\*
http://brunorocha.org
rochacbruno (Bruno Rocha) · GitHub
http://linkedin.com/in/rochacbruno
Google Workspace Updates: New community features for Google Chat and an update on Currents
<Google Workspace Updates: New community features for Google Chat and an update on Currents;

Topic		Replies	Views
Validation of nameko Usage Pattern googlegroup	6	1071	December 7, 2016
Nameko RPC & RESTful	3	1038	January 5, 2021
N00b Question on Connecting Client to Nameko server	3	583	June 24, 2019
monolithic and microservice services googlegroup	2	356	August 19, 2016
Nameko's performance Github Issues	10	1822	August 13, 2018

New blog post: Microservices with Python, RabbitMQ and Nameko

Related Topics