What do you want in Faraday 1.0?

[technoweenie]

• Parameter encoding tweaks. Introduces a parameter encoder option to connections. #199
• Use structs for the env, not nested hashes. Validation of hash key arguments. #136
• Pull out adapters as separate gems. Faraday-Typheous, Faraday-Patron, etc.
• Streaming? Streaming #156
• New Builder with separate request/response stacks. Instead of having everything a single stack of modules, have a stack of request and response modules, and a swappable adapter. This seems to hang people up. Can we implement this without breaking everyone's code though?

[eric]

👍

[mislav]

I think separate request/response stacks are interesting and worth exploring. I would definitely start with a subset of that idea and just extract adapters out of this whole things as endpoints not middleware (#47) which also makes them easily swappable (common pitfall), ensures that they don't end up elsewhere that is not at the end of middleware stack (common pitfall) and makes some implementation code simpler. I'm going to do this soon in a backwards-compatible manner.

[technoweenie]

I took a completely different approach and broke away from Rack completely: #207

It slaughters backwards compatibility, but I really like how simpler the middleware (now called callbacks) and adapters are.

[pezra]

I don't know if faraday is the layer for this but i'd like a futures/promise based interface for making http requests. ie, i call conn.get { ... } and i get a response object back before the request has actually completed. The request would take place in the background and the response would be populated once it was complete. If i accessed anything on the response object it would block until the request was complete and then do whatever.

This would make it fairly easy to make several http requests at the same time. All that would be required is to just make one call right after another. The gory details are hidden so that clients that don't need/want concurrent requests could carry on as if the requests where made synchronously.

[technoweenie]

@pezra: That's currently possible with Typhoeus, and maybe EM? You need to make a batch of requests with the same parallel manager (which is the Hydra object in Typhoeus 0.4, and something else in Typhoeus 0.5).

I'm really hoping that I can get it to work with the new builder stuff. It's one of my required features before I merge that branch into master.

[pezra]

Typhoeus and EM handle concurrency quite differently (and sort of awkwardly, imo). In Typhoeus, if i understand it correctly, you must define all the requests you want to run in parallel in a single block and none of the responses are available until all have completed. This introduces unnecessary latency for short requests in a batch. It also requires that you reorganize your code in order to use this feature. With EM you need to get involved in the whole async io quagmire to accomplish this. :)

The goal of a futures based approach is that it would provide improved latency for http requests in a transparent and comfortably OO way. In the best case doing exactly what is done now goes a lot faster and in the worst case the performance is unchanged.

This could be implemented above the faraday level but i thought i'd throw it out there to see if it has legs.

[ismell]

I would like to see some support for Digest Auth: https://github.com/technoweenie/faraday/issues/109 :)

[hanshasselberg]

@pezra @technoweenie You still do async requests with Typhoeus::Hydra with Typhoeus version 0.5.
@pezra Responses are available through callbacks as soon as they arrive:

request = Typhoeus::Request.new("www.exmple.com")
request.on_complete{ |response| p "completed" }

hydra = Typhoeus::Hydra.new
hydra.queue(request)
hydra.run
#=> "completed"

That way you don't have to wait until the Hydra#run returns.

[oriolgual]

@ismell I've been working on a DigestAuth middleware (here and here). I still need to add documentation but right now it works (at least with NetHTTP). I was thinking of sending a PR with it, so feedback is appreciated :)

[ismell]

I vote for persistent connections? Looking at the net-http-persistent adapter it seems to recreate create the connection for every request.

[mislav]

@ismell It may appear so, but it doesn't. All instances of NHPersistent use the same connection pool.

[ismell]

Oh well good to know :) Thanks!

[marshall-lee]

Maybe convenient method for constructing a connection pool using connection_pool gem?

[mnussbaumer]

A in-depth tutorial!

[iMacTia]

Closing in favour of #620