Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Dani Guardiola
    @DaniGuardiola
    Trying to user worker_factory but I don't know how to pass arguments to the service class constructor
    Is there any clean way of doing this?
    Dani Guardiola
    @DaniGuardiola
    Trying to use*
    Matt Yule-Bennett
    @mattbennett
    @DaniGuardiola Nameko service classes should not have custom constructors. They are stateless and not instantiated like normal objects in the OOP sense. All state should live in dependencies. The worker_factory is for providing alternative dependencies when creating a service worker.
    You might want to post a question on https://discourse.nameko.io to get more information.
    李满满
    @forcemain
    hi
    Matt Yule-Bennett
    @mattbennett
    :wave:
    Davis Kirkendall
    @daviskirk
    Is there a roadmap for when 3.0 is coming out? There are a lot of nice changes to the rpc implementations that we really like (nice work on that by the way)
    Matt Yule-Bennett
    @mattbennett
    @daviskirk no definite timeline, but should be soon. It's been out in prerelease for long enough for us to feel confident. @iky just has a couple more tweaks to the config changes that he wants to make
    in the mean time you can install the prerelease now with pip install --pre nameko. more prerelease users are always appreciated
    Gustavo Gawryszewski
    @gawry
    How would you compare nameko with Celery and Dramatiq?
    Matt Yule-Bennett
    @mattbennett
    @gawry if you ask this question over on the forum (https://discourse.nameko.io) i'll be able to give a more in-depth answer. the gist is that celery and dramatiq are for outsourcing jobs to workers, whereas nameko is a framework specifically designed for creating microservices
    there is quite a lot of overlap though. you could absolutely build a celery or dramatic in nameko if you wanted to
    Gustavo Gawryszewski
    @gawry
    I know that Nameko offers an RPC interface which makes easier the communication with other applications easier, and Dramatiq does not even thought that could be built. Do you think it makes sense to build a Nameko service to build a bridge to a Dramatiq application so other services can connect in an easier way?
    Matt Yule-Bennett
    @mattbennett
    I don't know enough about Dramatiq or your use-case to comment really
    Gustavo Gawryszewski
    @gawry
    As far as I could tell it's pretty much like celery but a bit simpler.
    I'm trying to figure out how to structure my architecture
    Matt Yule-Bennett
    @mattbennett
    If possible, give an overview of what you're trying to achieve on a post at https://discourse.nameko.io
    Matheus
    @mths0x5f

    well.. newbie question (to nameko and Microservices in general), but the Gateway Service "pattern" is the only recommended approach for exposing APIs for another services?

    it seems to me more than a single point of failure but a point of huge cognitive overload

    I was thinking of exposing rest apis in each service and then using an general porpoise reverse proxy... or, if this thing exists, an API Gateway that can communicate directly with nameko services through RPC
    Matt Yule-Bennett
    @mattbennett
    @mths0x5f you use the API of the services directly, for sure. The gateway pattern is useful when you want to have another layer that aggregates together APIs from multiple services, rather than putting that logic in the client. When you need it, this is usually less cognitive overload than having it all in the client. Especially if you have multiple clients.
    You might be interested in this example using GraphQL and gRPC: https://github.com/nameko/nameko-examples-grpc
    ardenn
    @ardenn
    @mattbennett Any ideas on how to setup debugging for Nameko in VSCode?
    Matt Yule-Bennett
    @mattbennett
    @ardenn I'm afraid not, I use Sublime and debug in the terminal. @kooba uses VSCode... he may be able to help
    ardenn
    @ardenn
    Thanks @mattbennett . @kooba Any ideas?
    Jakub Borys
    @kooba
    @ardenn I've gotten used to debugging in terminal. It's a breeze when used with pdb++ Never tried to do it in VSCode unfortunately.
    ardenn
    @ardenn
    @kooba I guess I've gotten tired of constantly having to edit my code to add pdb then back again to remove it
    litnimax
    @litnimax
    Hi folks!
    I would like also to get AMQP messages to handle smth like a subscribe to a topic and get updates from the queue.
    From docs I understand that Events (Pub-Sub) is not what I need, correct?
    Thx
    litnimax
    @litnimax
    Like in nameko-redis-py I see PubSub Response Listener
    litnimax
    @litnimax
    smth like:
    @amqp('example.route1')
    async def route1b(self, data: Any) -> None:
    self.log('Received data (function: route1b) - "{}"'.format(data))
    litnimax
    @litnimax
    Marwan Rabbâa
    @waghanza
    hi,
    we want to add nameko is our benchmarking project => the-benchmarker/web-frameworks#1269
    do you consent on such a thing ?
    Matt Yule-Bennett
    @mattbennett
    hi @waghanza, ya of course. am curious to see the result
    Marwan Rabbâa
    @waghanza
    thanks @mattbennett, seems that nameko perform really badly
    | Language | Framework | Average | 50th percentile | 90th percentile | Standard deviation | Requests / s | Throughput |
    |----|----|--------:|------------:|--------:|---------:|-------:|----|
    | python (3.7)| japronto (0.1) | **4.74** ms | 4.15 ms | 9.58 ms | 3801.00 | 191383.33 | 15.18 Mb |
    | python (3.7)| falcon (2.0) | **11.74** ms | 10.05 ms | 19.82 ms | 6678.33 | 79730.67 | 12.38 Mb |
    | python (3.7)| bottle (0.12) | **15.21** ms | 12.60 ms | 24.85 ms | 8697.00 | 62003.67 | 10.13 Mb |
    | python (3.7)| asgineer (0.7) | **17.72** ms | 15.48 ms | 29.57 ms | 9034.00 | 52988.33 | 6.27 Mb |
    | python (3.7)| blacksheep (0.2) | **18.58** ms | 16.81 ms | 29.41 ms | 8565.33 | 49853.67 | 6.65 Mb |
    | python (3.7)| hug (2.6) | **18.62** ms | 14.86 ms | 31.37 ms | 11104.33 | 50375.33 | 8.28 Mb |
    | python (3.7)| starlette (0.12) | **19.34** ms | 17.18 ms | 32.22 ms | 9976.00 | 48439.67 | 6.92 Mb |
    | python (3.7)| clastic (19.9) | **35.16** ms | 30.26 ms | 54.82 ms | 14244.67 | 26162.00 | 4.30 Mb |
    | python (3.7)| fastapi (0.42) | **35.41** ms | 30.42 ms | 60.55 ms | 19508.33 | 27154.33 | 3.89 Mb |
    | python (3.7)| molten (0.27) | **38.26** ms | 32.04 ms | 56.36 ms | 18283.33 | 24758.33 | 3.05 Mb |
    | python (3.7)| aiohttp (3.6) | **38.96** ms | 35.55 ms | 58.91 ms | 14442.33 | 23819.67 | 3.58 Mb |
    | python (3.7)| flask (1.1) | **42.25** ms | 37.08 ms | 64.19 ms | 20112.67 | 21772.67 | 3.56 Mb |
    | python (3.7)| sanic (19.9) | **44.89** ms | 40.75 ms | 71.11 ms | 20225.33 | 20474.00 | 2.42 Mb |
    | python (3.7)| bocadillo (0.18) | **46.12** ms | 40.05 ms | 78.93 ms | 24297.00 | 20486.33 | 2.62 Mb |
    | python (3.7)| quart (0.10) | **77.16** ms | 64.68 ms | 131.77 ms | 35262.00 | 12008.00 | 1.59 Mb |
    | python (3.7)| responder (1.3) | **92.84** ms | 84.83 ms | 153.63 ms | 35912.67 | 9883.33 | 1.43 Mb |
    | python (3.7)| tornado (5.1) | **102.96** ms | 96.28 ms | 142.19 ms | 37102.00 | 8784.00 | 1.73 Mb |
    | python (3.7)| django (2.2) | **104.97** ms | 89.79 ms | 166.26 ms | 44089.67 | 8669.00 | 1.67 Mb |
    | python (3.7)| masonite (2.2) | **124.16** ms | 109.88 ms | 208.84 ms | 47032.00 | 7241.00 | 1.18 Mb |
    | python (3.7)| cyclone (1.3) | **364.58** ms | 314.85 ms | 391.55 ms | 459904.00 | 2264.33 | 0.38 Mb |
    | python (3.7)| nameko (2.11) | **658.48** ms | 646.13 ms | 675.69 ms | 488592.33 | 1221.67 | 0.17 Mb |
    Matt Yule-Bennett
    @mattbennett
    hmm. surprising that it is so much slower than flask, given that nameko.web is a very light wrapper around werkzeug. thank you for adding it anyway.
    Matt Yule-Bennett
    @mattbennett
    oh -- you've not increased the default number of workers. i have commented on the PR
    @waghanza ^^
    Marwan Rabbâa
    @waghanza
    @mattbennett yep, this was run before :stuck_out_tongue:
    I've set max_workers to 5000 since the concurrency is 1000
    am I right ?
    Marwan Rabbâa
    @waghanza
    @mattbennett it leads me to a latency average of 449.16ms
    Matt Yule-Bennett
    @mattbennett
    thanks. still surprisingly slow! 5000 should be fine. will be interesting to see if we can improve this in time.
    Marwan Rabbâa
    @waghanza
    Davis Kirkendall
    @daviskirk
    I'm not 100% about the exact setup it's running under but I saw that the flask setup uses gunicorn + meinheld and while meinheld also uses greenlet I believe that gunicorn will still use multiple processes (and cores) which should add additional parallelism compared to "straight" eventlet (which nameko uses). Note that I am not a gunicorn/meinheld/eventlet/expert and even if this were true the performance compared to flask would still be bad
    Marwan Rabbâa
    @waghanza
    @daviskirk you're right. I have used meinheld since it adds someking of parralelism to gunicorn, I do not know to do such things with nameko, but feel free to tell me. It will be a pleasure to update codebase :heart:
    Sivabudh Umpudh
    @sivabudh
    Hi
    Is it possible to run a nameko service inside a Django application?
    Specifically, I would like to run an event_handler service inside a Django application. If I created a custom Django management command and put invoked the event_handler service via nameko's ServiceRunner, will that be alright?
    Matt Yule-Bennett
    @mattbennett
    @sivabudh that won't work -- Nameko uses eventlet and relies on its event loop to be running somewhere. What is your use-case for putting Nameko inside Django? seems like a strange one