Ruby Rack-like protocol for web applications

[RobertD]

Hi,

This is my first post on the list but I've been following it for a couple of weeks now.

So what I'm willing to ask is if there have been any discussions regarding "standardizing" a WSGI/Rack-like protocol for Go web applications?

I have some spare time and I would gladly invest it in working on such a project.

So I'm asking you hoping that we can discuss some aspects of such a spec, for example:

- what did wsgi/rack got right

- what did wsgi/rack got wrong and how can we fix that in our protocol

- etc.

And if coming to the conclusion that this is necessary/useful publish the spec and its implementation.

Thank you for your time.

BR,

Robert

[Andrew Gerrand]

The more interesting question, to me, is: what is the relevance of
WSGI with respect to Go? Where and how do people want to use it? By
implementing and standardizing an equivalent, what problem are we
solving?

Andrew

[RobertD]

First let's take a look at PEP 333 [1] to find out why WSGI was adopted

by the Python community in the first place. The Abstract section says:

"This document specifies a proposed standard interface between web

servers and Python web applications or frameworks, to promote web

application portability across a variety of web servers."

Also, in the Rationale section we find out that:

"Python currently boasts a wide variety of web application frameworks,

such as Zope, Quixote, Webware, SkunkWeb, PSO, and Twisted Web -- to

name just a few. This wide variety of choices can be a problem for new

Python users, because generally speaking, their choice of web

framework will limit their choice of usable web servers, and vice

versa."

and that:

"The availability and widespread use of such an API in web servers for

Python -- whether those servers are written in Python (e.g. Medusa),

embed Python (e.g. mod_python), or invoke Python via a gateway

protocol (e.g. CGI, FastCGI, etc.) -- would separate choice of

framework from choice of web server, freeing users to choose a pairing

that suits them, while freeing framework and server developers to

focus on their preferred area of specialization."

Coming back to Go, and asking ourselves "Do we face the same problems

described by PEP 333 in Go?", the obvious answer is "No". Why? Mainly

because we have only a handful of web frameworks, none of which is

mature enough or widely used. Also almost everyone is using the web

server supplyed by Go in the "http" package for implementing web

services and/or applications. However, I think it will come a point

when this will inevitably change: the number of frameworks will grow,

people will write a number of web servers, etc. and they we will want

to be able to reuse functionality already implemented by other

frameworks.

My rationale is that it would be great to learn from Python and the

impact that WSGI had for the Python web community (or Rack for the Ruby

community) and don't repeat the same mistakes that others have done in

the past.

[1] http://www.python.org/dev/peps/pep-0333/

[André Moraes]

FCGI does that don't?

Most of the modern web servers support FCGI. FCGI put my application
logic separated from my webserver process, so a crash in one don't
affect the other.

FCGI is like CGI, but go one step ahead and make persistent
connections (PIPE or TCP) and so unlike CGI, each request don't fork a
new process.

--
André Moraes
http://andredevchannel.blogspot.com/

[Brian Ketelsen]

On Jan 4, 2011, at 9:07 AM, André Moraes wrote:

FCGI does that don't?

I can't speak for WSGI, because I come from the Ruby/Rack side of the world.  But Rack is much more than a server communication protocol.  Rack also defines a consistent API for web applications to interoperate on the same Request/Response.  This allows a developer to use any web framework to build the core application, for example, but use a different Rack application for Authorization.  Doing this means that no matter how many apps I write, they can all use the exact same authorization code, which I've only written once.  Rack allows these micro-applications to be inserted in the http request/response pipeline, and they can either modify the request/response or they can simply observe.

Here's a list of some of the Rack middleware that's available.  It seems to be fairly current:

http://coderack.org/middlewares

And here's a nice overview of Rack + Rack Middleware:

http://amberbit.com/blog/introduction-to-rack-middleware

For the original poster, I'd be interested in exploring this.  

Brian

[André Moraes]

Begin of Personal opinion:
I really don't like huge frameworks (Rails, Spring) that do too much
and everything works like magic. I really prefer to have control over
how things are done, or at least, know the magic behind.

Maybe Rails isn't all that magic, but for me it looks like, So maybe I
just don't know rails well.
End of Personal opinion

The HTTP pipeline is really usefull and I agreed that it should exist
and if exists will be helpful and useful too. +1 to that idea.

But we don't need other API to do that, http package has support for
HTTP Headers and mime package can read/write multipart http
request/response body.
So, to build a pipeline you just need to add a collection handlers
that will work on some request.

[Andrew Gerrand]

It seems to be that as long as any web framework is written to support
the http.Handler interface, the actual http end can be handled by the
built-in http server or a WSGI or FastCGI implementation that expects
http.Handlers.

As far as Rack's 'middleware', it's easy enough to write an http
Handler that wraps another Handler.

Maybe that's enough to keep the various frameworks compatible, and
avoid the issues that brought WSGI into existence. It's hard to
predict the future.

Andrew

[RobertD]

It is indeed thoughtful. Thank you for your time.

Robert