New blog post: Microservices with Python, RabbitMQ and Nameko

Microservices with Python, RabbitMQ and Nameko

1 Like

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 :wink:

···

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

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

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

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 :wink:

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
http://github.com/rochacbruno
http://linkedin.com/in/rochacbruno
http://plus.google.com/+BrunoRocha1 <http://plus.google.com/+BrunoRocha1>

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
http://github.com/rochacbruno
http://linkedin.com/in/rochacbruno
http://plus.google.com/+BrunoRocha1 <http://plus.google.com/+BrunoRocha1>

I updated the post and example code available
here: https://github.com/rochacbruno/nameko-example (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

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

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 :wink:

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
http://github.com/rochacbruno
http://linkedin.com/in/rochacbruno
http://plus.google.com/+BrunoRocha1 <http://plus.google.com/+BrunoRocha1>

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
http://github.com/rochacbruno
http://linkedin.com/in/rochacbruno
http://plus.google.com/+BrunoRocha1 <http://plus.google.com/+BrunoRocha1>

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
http://github.com/rochacbruno
http://linkedin.com/in/rochacbruno
http://plus.google.com/+BrunoRocha1
<http://plus.google.com/+BrunoRocha1>

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
http://github.com/rochacbruno
http://linkedin.com/in/rochacbruno
http://plus.google.com/+BrunoRocha1
<http://plus.google.com/+BrunoRocha1>