Problems: 1. Client credential management (for multi-user tools.) That parts relatively easy, but probably his best practices.
-
-
Show this thread
-
2. Rate limit management. So many libraries seem just puny on this and listen for 429 or whatever statuses as a signal to wait. My solution uses resource checkouts and updates remaining requests, but adds complexity. Being a rude consumer seems easier!
Show this thread -
3. Returning responses Here’s the latency thing. If I have a request that will take many minutes if not hours or days, it’s either a callback or push to a message broker or something. But there is a resource usage issue for queued requests and responses!
Show this thread -
Most most recent pass essentially used a map[uuid]*Response for each request that had a timeout for deletion, with polling for completion. But it feels fragile AF and I’m not going to use it. So now that I have intuition I’d like to skip to other people’s good ideas.
Show this thread
End of conversation
New conversation -
-
-
The patterns and implementations described in the ZeroMQ guide are a great - http://zguide.zeromq.org/py:all#reliable-request-reply …
- End of conversation
New conversation -
-
-
You’re reliant on weak information from the API. afaik polling is your only option, ie, all the accounting belong to you

- 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.