Re: [RFC] proxy_pass: document as public API

[Eric Wong <e@80x24.org>]

"Lin Jen-Shin (godfat)" <godfat@godfat.org> wrote:
> On Sat, Feb 20, 2016 at 4:16 PM, Eric Wong <e@80x24.org> wrote:
> >  Any thoughts?  So far I've resisted having a public API.
> >  On the other hand, the current state of ProxyPass being a
> >  Rack app using rack.hijack still has nasty limitations
> >  such as incompatibility with any existing middleware.
> >  Something simple such as access logs won't work well
> >  (e.g. Rack::CommonLogger or Clogger)
> 
> My first impression was that why not put this in a separate
> gem, say yahns-apps or so? I am not saying we should do
> this, just curious why? Easier to maintain and distribute?

Yes, easier to maintain + distribute since it depends on yahns
internals.

> >  On the other hand, it would be nice to have a mostly-Ruby
> >  alternative to nginx today...
> [...]
> 
> I am even more curious to this. Nginx is pretty accessible already,
> (perhaps not on Windows though?) and it would surely be more
> performant than Ruby. Or is it because we might want to make it
> not only a reverse proxy, extending it with Rack middleware?

I'm not up-to-date with current nginx versions, but proxy output
buffering in nginx could not be lazy when I checked.  It had to
either not buffer at all or buffer entirely (the default) before
writing to the client.

Also, being a Rack app also means an app could migrate
thread-safe endpoints to yahns (running normal Rack directly),
while forwarding non-thread-safe endpoints to unicorn or
whatever else.

nginx has a better chance of working on Windows than yahns :)
I've always been openly against wasting time on non-Free OSes.

> If so, then we probably don't want this directive:
> 
>     app(:proxy_pass)
> 
> but just treat it as a Rack application? Or we might want to define
> another middleware, say proxy_pass's middleware, which would
> be slightly different than the rack ones? If so I think it makes a lot
> of sense to have app(:proxy_pass).

Right, I'm leaning towards leaving it as a Rack app.

If we want to define a new middleware API, it would be a new
ecosystem.  If that were easy, Rack would've done it by now :)

So perhaps it's better to provide some sort of API (like the
(seemingly abandoned) rack_after_reply RubyGem) which
which existing middlewares could be slightly modified to
opt-in to.

Fwiw, I mainly want to use clogger with this for access logs
<http://clogger.bogomips.org/>.  I believe other application
logic should reside in the application server, including
things like Rack::Deflater.

Anyways, I'd prefer to move slowly and cautiously with this
so I'm unlikely to finalize anything before April or even May.