Adapters should be Rack apps not middleware

[mislav]

This is our current Rack app (i.e. the "inner app" wrapped by middleware):

app = lambda { |env|
  response = Response.new
  response.finish(env) unless env[:parallel_manager]
  env[:response] = response
}

It's really kind of a hack. I think our adapters should each perform this and stop acting like middleware when they really play a role of an endpoint. I can't think of a use case where you would want to mount middleware after the adapter.

[myronmarston]

FWIW, my VCR gem includes a Faraday middleware that acts a bit like middleware and a bit like an adapter. Basically, it delegates to the faraday http client adapter the first time you run your tests and it records the responses. The next time you run your tests, it returns the recorded responses so you have fast, deterministic tests. It's a bit like Faraday's built in test adapter, but VCR's faraday middleware relieves you from the need of figuring out what the stubbed responses should be as it takes care of recording an actual response to use.

I'm not sure if it has any bearing on this issue, but I thought I'd mention it (especially because the 0.6 release broke VCR's faraday middleware--it'd be nice not to have that happen again). If you're curious, the implementation is here and usage documentation is here.

[mislav]

Your VCR thing is a kind of caching middleware in a way that it sometimes lets requests reach the adapter, but sometimes halts the call chain and returns a baked response. I have a Caching middleware in faraday-stack, if you want to take a look.

Your use case is certainly interesting (and cool!) but it doesn't really have relevance in this matter. Even if I change how adapters behave, it won't ever affect any middleware such as yours. It might only break 3rd-party adapters, and I'm not aware of such existing.

We'll try to not break stuff so horribly from now on. If a future update breaks your stuff, please file an issue and let us know.