I spent this last week or so working on an idea. It's an idea I've had for a while. Ever since I wrote Mongrel and got stuck doing Ruby I've wanted a web server that loved all languages. A web server that broke the strict request/response pattern and let you scale out your application so that one browser request could be mapped to as many backends as you needed. A server that let you do both HTTP, Flash Sockets, and WebSockets on the same port with no configuration.

A web server simply written in C that loved all languages equally. When I wrote the original Mongrel I wanted to make a server that loved all Ruby web frameworks equally. Rather than make it Rails specific I wanted everyone to have a chance, and the end result was many nice frameworks and Merb eventually taking over Rails.

I wanted to do this same thing for all programming languages.

This week, I finally started that web server and I named it Mongrel2. It took me about 1 week to get a first functioning version up once inspiration hit me of how exactly I could do it. This version is functional enough to be self-hosting and support a mostly working web chat server. The code for this is currently about 366 lines of C and 57 lines of hack Python plus some supporting libraries.

Warning: it will crash. But give it a try. It's kind of fun.

What you are looking at is a server that servers both Flash Sockets and HTTP traffic on the same port with routing to TCP and 0mq backends. Connect to mongrel2.org:6767 with a browser and Mongrel2 figures out it's HTTP. Connect with telnet and it's a JSSocket. Connect and give the Flash Socket stanza and it's a Flash Socket. This is done with enhancing the Mongrel HTTP parser with extra rules for the other protocols, and means that when WebSockets are available Mongrel2 will be ready to go.

All of these are then sent to backend servers using either raw TCP/IP or ZeroMQ. The HTTP requests are proxied to an nginx server, with full keep-alives and all. The JSSocket JSON messages are routed to the Python backend and it does all of the control to implement the chat service. There isn't any more logic in the Mongrel2 code than is necessary to move requests to backends and maintain sockets.

Let This Sink In For A Moment

Think about this for a moment: HTTP requests translated to X number of 0mq requests of any style to create the response. That means, PUB/SUB, REQ/REP, and even multicast requests to any programming language. In fact, you could mix and match programming languages as needed, replace them when they start to suck, etc.

It may not dawn on you quite yet, but I think this design has a very good chance of changing how we architect and deploy web applications. Imagine if you had available to you reliable asynchronous and synchronous web protocols, and that all of the messages from those protocols were transported to your backends with no regard for what language they were written in? Not only that but it wouldn't even care how many backends you had or where they were located.

Like a NoSQL cluster for your application logic, this could probably bring about some incredibly cool applications you hadn't thought of before. Imagine a web service that stores and retrieves files from backends using an 0mq OpenPGM multicast scatter off of a single HTTP request. This is the kind of changes I'm thinking off, not just "better routing" or the "sqlite config database" stuff. That's all fluff compared to what can really be done with this idea.

Status

If you want to take a look at the beginnings of the code, read more about it, and possibly help out check out the Mongrel2.org site. You can try grabbing fossil and building it, but I'd wait a few weeks until I have the foundation laid down better.

Are You Doing A Chat Application?

I'm finding Mongrel2 works great for a chat application, and I'm looking for other people working on similar web applications. If you're doing one, email me and let me know if I can come by and pick your brain about things you need.