Victus Spiritus

pancake stacks are better than web stacks

Let's follow some bytes as they make the journey from their source server  to a client system over HTTP.

1. Server Hardware
2. Server Software
3. Script + Web Page Markup
4. Routing Hardware/Network
5. Client Browser
6. Client Hardware

Choice layers explained

Server Software

• App Server
  • Logic/Algorithm
  • Web Framework
  • ORM
  • Database
• Web Server (Reverse Proxy)

The App Server creates the dynamic web content for a site and is the culmination of customized logic that leverages a web framework, ORM, and database to serve up web pages.

Web Framework defined:

A Ruby framework is collection of pre-written libraries, functions and controls that can be downloaded and used to make your programming task easier. In addition to a time saving, there is also a significant benefit in terms of programming efficiency and implicitly a more consistent programming style (since so much is pre-defined, one begins to use or utilize the paradigm of the underlying framework when writing a program)

ORM defined:

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in relational databases and object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.

Web server Reverse Proxy defined:

Another Web Server?

At this point you may be wondering why people are talking about using Apache or Nginx in their stack. Don’t we already have a web server? We do, but the Ruby app server is not a full-featured web server, and it’s not very good at sending images and other kinds of static files (in fact all app servers are terrible at this, which is why it’s better to call them “app servers” than “web servers,” though the two terms are often used interchangeably). So what we want to do is use a general purpose web server for static files, and pass other requests along to our app server.

This is one of the most complicated and least standardized parts of Ruby web app configuration. Serving static files and handing off requests doesn’t take much processor power, so for a small web site our web server shouldn’t be too busy. The app server, on the other hand, is running our complicated Ruby application, and could be quite busy. For this reason one usually deploys multiple app servers (listening on different ports) for the web server to choose from when a request comes in. The process of handing requests off to these servers is called reverse proxy.

(If you’ve worked for a large company you’re probably familiar with accessing the Internet through a forward proxy server. Forward proxy is for outbound—client-side—requests, reverse proxy is for inbound—server-side—requests.)

Ron called out an incorrect mixing of layers, so here's a shot at clearing up the discrepancy.
Script + Web Page Markup

• content (text, audio, video)
• Graphics, Image editing
• CSS styling
• scripting (Javascript/AJAX)
• HTML page

Routing Hardware/Network Layer
Client Browser

• script interpreted at Client side (Javascript/AJAX)
• final HTML page rendered and interpreted

Simple Example of Server Software

Sinatra (framework) using Datamapper (ORM) with Sqlite (database) & Thin (web server)

References:

• The last time I talked about HTTP details was a Peer 2 Peer notion
• Alex Reisner's Anatomy of a Ruby Web Application
• I was happy to get additional inspiration for this post from this SoloSignal.com post after a little searching. Here's Solo's web stack:
  1. Physical Server and Infrastructure
  2. Web Server Software
  3. Database Management System
  4. Business Logic Programming
  5. HTML and Markup
  6. Cascading Style Sheets
  7. Graphic Design
  8. Client-side Scripting