Notifications
You’re not receiving notifications from this thread.
API HTTP Requests using Faraday Discussion
One question I have, there is no retry option given. Does it makes sense on original implementation to leave the retry out? We are trying to make the code as robust as possible and in case of timeout or when Vultr servers are down, what should this code do?
Should we just use this type of wrappers inside some redis-queue like Sidekiq so it is automatically retried for us?
Hey! I'm having trouble when running bin/console. The variable we define in the console isn't available when I run the command. Looking at the source code, it looks like I have things set up correctly. Any help would be appreciated!
Also ran into this issue. When converting to an instance variable, this worked. @stephen, did you run into any errors after this? Or were things successful for you?
Thanks.
That's odd. I cloned the repo down and tried running bin/console and had no issues accessing client as a local variable instead of an instance variable.
What error are you folks getting? That it's an undefined local variable?
Just cloned the repo and am running into the same issue:
irb(main):001:0> client
Traceback (most recent call last):
2: from bin/console:21:in `<main>'
1: from (irb):1
NameError (undefined local variable or method `client' for main:Object)
If I set as an instance variable: @client = Vultr::Client.new(api_key: ENV["VULTR_API_KEY"])
Result:
irb(main):002:0> @client
=> #<Vultr::Client:0x000000012232a730 @api_key=nil, @adapter=:net_http, @stubs=nil>
irb(main):003:0>
I'm currently going through the video and as of faraday 2.0, the faraday_middleware gem has been deprecated and most adapters have been bundled into the faraday gem. More details here: https://github.com/lostisland/faraday/blob/main/UPGRADING.md
Do we need to treat the api_key attribute of the Vultr client we create with any sensitivity? We have encrypts :token for ActiveRecord attributes but these are PORBs.