New blog post: Microservices with Python, RabbitMQ and Nameko

[Bruno Rocha]

Microservices with Python, RabbitMQ and Nameko

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

[Matt Bennett]

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 ;-)

[Bruno Rocha]

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.

--
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.
To post to this group, send email to namek...@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.
For more options, visit https://groups.google.com/d/optout.

--

Bruno Rocha - @rochacbruno

http://brunorocha.org

http://github.com/rochacbruno

http://linkedin.com/in/rochacbruno
http://plus.google.com/+BrunoRocha1 

[David Szotten]

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

https://github.com/onefinestay/nameko/blob/master/nameko/web/handlers.py#L25

David

[remco....@gmail.com]

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:

[Bruno Rocha]

 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.

[David Szotten]

async without waiting:

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

[remco....@gmail.com]

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:

[David Szotten]

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

[7oo...@gmail.com]

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?

[Bruno Rocha]

I updated the post and example code available here: https://github.com/rochacbruno/nameko-example  (suggestions and PRs are welcome)