Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Matt
    @iMacTia
    Here you can see an example of creating a connection object with the headers option
    Márcio Soares
    @biodevs
    Hello, I would like some help on a faraday.get connection that always returns a TrueClass and not a Faraday::Response in rails. I will be grateful for the attention.
    Matt
    @iMacTia
    Hey @biodevs, happy to help. Probably the issue is with the way the connection is setup. Could you please open an issue in the Faraday repo and share as much details as possible?
    satya konidala
    @satyakonidala

    Hi, How do I use faraday to run requests parallelly when there is dependency among requests? For example, consider the below scenario:

    Main Dep1 Dep2
    1 -> 1.1 -> 1.2
    2
    3 -> 3.1 -> 3.2
    4 -> 4.1

    You can read the above as the app wanting to make a total of 9 requests with requests under Dep1 and Dep2 depending on the response from the main request. So, request 1.2 depends on request 1.1 which in turn depends on main request 1.

    Rod Jenkins
    @scriptmonkey
    Hello Ll
    Rod Jenkins
    @scriptmonkey
    Hello all, I’m new around here. I have a newbie question. I need to be able to use Faraday to send a POST, “application/json”, but with a null body.
    Rod Jenkins
    @scriptmonkey
    I can provide the curl command I am trying to replicate if the is helpful.
    Matt
    @iMacTia
    Hi @satyakonidala :wave:! Faraday::Response offers a method called on_complete, you can use that to chain dependent requests. Sorry about that lack of documentation around this but parallel requests is not a strength for any of the remaining maintainers, so we struggle a bit to provide support on this topic. We hope to revamp and improve this in the next major version though :thumbsup:
    Please do let me know if the above works!
    Hi @scriptmonkey :wave:! The curl example would definitely help, because I'm not sure the JSON standard allows for a "null" body, just an empty one I believe. But if you're able to make it work with curl we most probably can make it work on Faraday !
    Rod Jenkins
    @scriptmonkey
    @iMacTia I do feel nice that there was not a silly simple answer. Here is the curl command:
    curl -X POST https://api.dropboxapi.com/2/users/get_current_account \ --header 'Authorization: Bearer mysupersecrettoken' \ --header 'Content-Type: application/json' \ --data 'null'
    Matt
    @iMacTia

    @scriptmonkey that looks to me like a simple string body with the word "null" is that it?
    In that case, I believe you should be able to set that as your request body and manually set the Content-Typeheader

    Faraday.post("https://api.dropboxapi.com/2/users/get_current_account", 'null', "Content-Type" => "application/json", "Authorization" => "Bearer mysupersecrettoken")

    Here is another example taking full advantage of Faraday tools and middleware, including those provided by the faraday_middleware gem:

    require 'faraday'
    require 'faraday_middleware'
    
    base_url = 'https://api.dropboxapi.com/2'
    
    conn = Faraday.new(base_url) do |f|
      f.request :authorization, :Bearer, 'mysupersecrettoken'
      f.request :json
    end
    
    conn.post('users/get_current_account', 'null')

    Please do let me know if this works!

    P.S. the second snippet allows you to reuse the same connection (conn) for all subsequent calls to the same API and it will automatically make the body as JSON (even if you provide a Ruby structure like a hash or array) and set your bearer token on all requests
    satya konidala
    @satyakonidala
    @iMacTia thanks for pointing out the on_complete function. Will check that out.
    satya konidala
    @satyakonidala
    I see that on_complete is used only with middleware but not with normal request-response. I am looking for implementations how typhoeus has on_complete (https://github.com/typhoeus/typhoeus#making-parallel-requests). Do you mind pointing me out to any available examples?
    Matt
    @iMacTia
    @satyakonidala yes you can also use that in your middleware if you want it to support async requests, but you can call on_complete on any Faraday::Response object and pass a block. That block will be called as soon as the request returns and the response is saved (or immediately, if that happened already). For example, try the following (extending typhous example here, not sure which adapter you're using):
    conn.in_parallel do
      response1 = conn.get('/first').on_complete { |response| puts response.body } 
      response2 = conn.get('/second').on_complete { |response| puts response.body }
      puts response1.body || 'nil'
      puts response2.body || 'nil'
    end
    I'd expect nil to be printed twice (last 2 lines) first, and then you should see the actual bodies being printed after the requests have been completed
    In your case, the on_complete blocks will trigger the next requests based on their dependencies
    Matt
    @iMacTia
    @satyakonidala full example (again, using typhoeus):
    require 'faraday'
    
    base_url = 'https://httpbin.org'
    
    conn = Faraday.new(url: base_url) do |builder|
      builder.request  :url_encoded
      # builder.response :logger
      builder.adapter  :typhoeus
    end
    
    conn.in_parallel do
      response1 = conn.get('/anything', {test: 'test1'}).on_complete { |response| puts response.body }
      response2 = conn.get('/anything', {test: 'test2'}).on_complete { |response| puts response.body }
      puts response1.body || 'nil'
      puts response2.body || 'nil'
    end
    satya konidala
    @satyakonidala
    @iMacTia Thank you so much! This should definitely help!
    David Friedland
    @nohat
    @iMacTia (@satyakonidala's manager here) we're looking at being able to enqueue more requests to the parallel manager inside the response block based on the contents of the response
    this doesn't appear to be possible with the current implementation of in_parallel, but we think it should be if the yield at https://github.com/lostisland/faraday/blob/main/lib/faraday/connection.rb#L379 passed in the parallel manager to the block
    is this a change that would likely get accepted if we submit a PR?
    Rod Jenkins
    @scriptmonkey
    @iMacTia Thank you for the response yesterday. I was making it too complicated trying to pass null as a value and not a string. What you proposed, worked just fine. Once I get the script working as I need, I will start digging in to the middleware portion. Thanks again.
    Matt
    @iMacTia

    @scriptmonkey that’s great to hear! Thanks for the feedback!

    @nohat ah I see your point, that way you can then reuse the parallel manager to enqueue the subsequent requests. Yeah that makes sense, I’ll happily review a PR that adds add. I’d just ask you to spend a little time improving the documentation around parallel requests with this new feature and with anything that you wished was there when you started working with them, you would be of great service to the Faraday community ❤️

    Akshat Karnwal
    @3minus1:matrix.org
    [m]
    Hi Guys. Does Faraday not work with Rails 6?
    I'm facing this error NameError (uninitialized constant Faraday)
    Rails version: 6.1.3.2 (using Zeitwork autoloading)
    Ruby version: 2.7.3
    Faraday version: 1.4.2
    1.2 version works fine
    Matt
    @iMacTia
    Hi! Faraday have no dependency with Rails or vice-versa, so you can use it in any Rails project. The problem with your error looks simply related to loading, possibly due to the new autoloader.
    Ensure that faraday is included in your Gemfile or as a dependency of a gem in it (you can check the Gemfile.lock), and that there’s no “require: false” option on it
    Akshat Karnwal
    @3minus1:matrix.org
    [m]
    Hey Matt. It does look like it's a problem with the new autoloader. I've double checked and Faraday is included in my Gemfile and is also present in my Gemfile.lock
    Again, version 1.2.0 works just fine. Any version above it seems to be facing this issue.
    Matt
    @iMacTia
    That’s really interesting, do you have a more detailed stacktrace by any chance? Trying to see if this is a direct usage or a dependency one
    Samuel Williams
    @ioquatix
    How do you create a Faraday instance with a proxy option?
            connection = Faraday.new(url: url, proxy: ENV['PROXY_URL']) do |faraday|
                faraday.response :logger
                faraday.adapter :async_http, **adapter_options
            end
    It doesn't seem to work for some reason
                            if proxy = env.request.proxy
    Is this how I get the proxy from the env within an adapter?
    Matt
    @iMacTia
    @ioquatix that is correct, when you provide the proxy option as a simple string (that's what I assume it's in your env variable), this is automatically used to instantiate a ProxyOptions object by the Faraday::Connection (see https://github.com/lostisland/faraday/blob/830b696ae7cbcdcaafe78deed7104e34792e5826/lib/faraday/options/proxy_options.rb#L11)
    And you're also correct as of how to get the proxy, using env.request.proxy, this should return a ProxyOptions object
    Matt
    @iMacTia
    However, as you can see from these tests it's sometimes a better idea to use the standard environment variables to manage proxy settings (e.g. http_proxy). This way you won't even need to pass it to the connection, it will be picked automatically for you!
    Samuel Williams
    @ioquatix
    I just released async-http-faraday with support for proxy and tidied up persistent connection support (by default)
    MaryamAdnan
    @MaryamAdnan3
    Hi :wave: I'm new to Ruby and Faraday. I have a use case in which I can get an existing Faraday connection instance with configured retry middleware but I need to override it with new retry configuration values. So far I am able to achieve this through deleting the existing Retry Middleware in @handlers array and then again initializing the connection object with retry middleware. Is there any other way to do it? I have a feeling I am not using the best practices of overriding connection here. Sample code is available here: https://gist.github.com/MaryamAdnan3/dc1e84674e37aea10e23ceb512e2992e
    Matt
    @iMacTia
    Hi @MaryamAdnan3! To be fair the Faraday::Connection is not meant to be changed once configured. The middleware stack is also locked once the first request starts, so your snippet will only work up until that point. Creating a new connection is actually the correct way of doing this. You normally would want a separate connection object for each API you need to interact with, rather than reusing the same one for all of them. If you provide more information on why you ended up wanting to remove the middleware, I can potentially suggest a better approach
    MaryamAdnan
    @MaryamAdnan3
    Thank you @iMacTia for helping me out here. so I have a requirement in which we have configured the Faraday connection object already with or without the retry_middleware and users can pass us retry middleware attributes separately like backoff_max, max_retries, etc and can ask us to override the existing connection object with the new retry_middleware. So basically if possible I want to override an existing connection object with new retry middleware attributes. but what I am getting from your conversation is that we must create a separate connection object with the new retry middleware and use it, we cannot override an existing one. I can create a new one but I want the passing Faraday connection objects properties in it as well along with the new retry configuration attributes being passed separately. Is there any way to do this? I am hoping I'm making myself clear here.
    Matt
    @iMacTia

    Yeah I think that's clear, thanks for the context @MaryamAdnan3! The most immediate thing that comes to mind would be to have a "connection builder" method that returns a new faraday connection based on some parameters. Something like this:

    def build_connection(retry_options: nil)
      Faraday.new(...) do |f|
        # other middleware
        f.request :retry, **retry_options if retry_options.present?
        # other middleware and adapter
      end
    end

    You could then use this method to build your original Faraday connection object as well, so you won't need to copy over the handlers from one to another since the configuration will live inside this method. I'm not sure if this is possible in your specific case, but it would definitely be the cleanest way.

    If you're not the one creating the original Faraday connection, then the only other option would be similar to what you're already doing, with the exception that you would need to always generate a new connection:

    1. Create a new connection (new_conn)
    2. Configure the new connection with all the middleware from the old connection (check @handlers to see them)
    3. Add the retry middleware to the new_conn
    4. Remember to always add the adapter as the very last

    This is definitely a "dirtier" solution, but unfortunately necessary if you don't control the original connection

    Pedro M B Leal
    @pedrombl
    Hi team! :wave:
    We would like to use a gem that has requires an outdated version of Faraday (<1.0). I am trying to verify if the version 0.17.4 is stable and if there are no known security issues with it. The idea is to start using it this older version and upgrade the gem to use a newer version of Faraday in the neart future so our service can also updgrade Faraday.
    Matt
    @iMacTia
    Hi @pedrombl 👋! Thanks for asking. The core team is not aware any security vulnerability and even if one was discovered we’d most definitely release a patch version of the 0.x stream to address that (assuming it’s an important one, obviously).
    So I’d say as temporary solution it’s perfectly fine to use 0.17.x, just don’t expect any new features!
    Pedro M B Leal
    @pedrombl
    Great, thank you Matt!
    Wei Jun
    @Physium
    Hi there, i'm trying to create a class around Faraday so that i can set certain default connection variables across the team. Currently, i'm using builder to define my connection settings, is there a way i can pass builder as a class arguement if i ever want to override the connection settings on a new class initalization?
    Matt
    @iMacTia
    Hi @Physium, I'm not completely sure I understand, but the Rack::Builder is an internal class and it's not supposed to be sent around or used as an argument. My suggestion, assuming I actually understood the problem :smile:, is to have a connection "factory" or builder method like the one I described a few messages above
    Wei Jun
    @Physium
    Hi all, is there a way test if a connection is set up with the respective params/options/middleware in rspec? context i'm creating a base class of sort with a default initializer that sets up connection. At the same time this class takes in a set of options which allows me to adjust connection configs accordingly on initalization. I looking for a way to test if the connection in rspec is configured correctly based on the options parse in, is there a way i can go about doing it?