Well worth navigating through - it just gets nuttier and nuttier. I certainly didn't know you could execute SQL queries against Drizzle from within your nginx.conf, parameterise them based on the query string, hash them to different backend shards and format the results as JSON...
Whoa, nginx can do a hell of a lot via conf scripting. You could build a semi-decent REST interface to a data source using the modules in this presentation...
I actually tried putting a website together in a similar fashion a while back. All the hacks quickly got difficult to maintain, and the code was ugly. I was too ashamed of what I've created to share it with the world. Now I see someone actually built up that courage :)
Not to nitpick, but I feel the need to point out that the "REST interface to memcache server" isn't really REST, since it's issuing non-idempotent commands using GET requests, with the command type and resource specified in the query string.
Yeah, that statement in my slides is incorrect :) But the ngx_memc module itself does support true REST interface setup. Please take a look at the samples in its documentation: http://wiki.nginx.org/NginxHttpMemcModule
GET /foo?key=dog
POST /foo?key=cat
Cat's value...
PUT /foo?key=bird
Bird's value...
DELETE /foo?key=Tiger
XSS seems as good a definition as any - everyone's calling it lots of things, JSONP or AJAST or whatever - but setting up data feeds inside javascript function calls specifically to do ajax-Y stuff but getting around the cross-site security model built into xmlhttprequest.
But XSS already has a different specific meaning. Granted it's a confusing definition for exactly this reason, but it's well established to mean a security vulnerability where an attacker can inject JavaScript into users pages thereby stealing their session cookies, etc. It has nothing to do with cross-domain requests.
If you're running a web scale operation then the ability to talk to memcached directly from nginx lets you do something like "Grab the page out of memcached if it is already there, if not, pass request to application server.", totally avoiding the application server and database for a huge portion of your "dynamic" requests. Given the relative costs of two roundtrips to memcached and e.g. going through the entire Rails stack, that is a bit of a win.
Still, it would be interesting with connections to real-life applications. I was hoping to figure out a few practical ways of using more of my nginx spare cycles. I'm sure there's a ton of cool stuff one could actually use this for, but I'm none the wiser after the presentation.
I must add that, the stuffs shown in these slides are just our "level 1 scripting". There will be level 2 and level 3, so as to support more sophisticated business logic in our data platform.
Level 2 will be ngx_lua scripting which provides Erlang-style transparent non-blocking I/O support and access to the whole nginx infrastructure and all the level 1 scripting goodies.
Level 3 will be...well...Perl 6, JavaScript, and PHP scripting atop the ngx_lua VM (by the corresponding X -> Lua compiler). grin We'll eventually get there.