HTTP request lifecycle

The life of a code.org HTTP Request

DNS resolution

code.org => (DNS managed by route 53) => 54.192.37.35 (...etc...)

(dig code.org => 54.192.37.35, whois 54.192.37.35 ^output shows it's an Amazon-owned IP, AMAZO-CF2 == CloudFront.)

CDN / load-balancer

CloudFront => Elastic Load Balancing [ELB]

ELB => => multiple Frontend servers (Elastic Compute Cloud [EC2] with Auto Scaling)

Frontend Server

Varnish Cache (port 80) => port 8080 (dashboard) or port 8081 (pegasus) (depending on Host header: code.org => pegasus, studio.code.org => dashboard)

NGiNX (port 808{0,1}) => Unix socket/s (/run/unicorn/{dashboard,pegasus}.sock)

Unicorn (UNIX socket/s) => Ruby application Rack server/s

Rack server definition files:

• dashboard: dashboard/config.ru
• pegasus: pegasus/config.ru

Pegasus web-application (/pegasus - code.org)

Web-application based on sinatra routing framework, with custom template and view-rendering layer.

• pegasus/router.rb: - class Documents < Sinatra::Base
  • Additional routes are in pegasus/routes/*.rb, which are all recursively inserted into the Documents class.
• get_head_or_post '*' - path == / for root page request
• resolve_document(uri) -> resolve_template('public', extnames, uri) - resolves a URI to a path on the filesystem ending in /public. A Sinatra before hook sets a directory to search based on the Host of the request prepended with sites.v3. (e.g.: GET / with header Host: code.org ultimately resolves to pegasus/sites.v3/code.org/public/index.haml on the filesystem.)
• document path - read path from filesystem and render output
• render_ content, extname - render content from template based on file extension
• after do (Sinatra after hook) - load and render layouts/ and themes/ templates from file:
  • layouts and themes 'wrap' themselves around the existing rendered body through the line: body render_template(template, @locals.merge({body: body.join('')})), which calls #body, which first reads (passed as a local variable to #render_template) and then updates the template-rendered result.

Dashboard application (/dashboard - studio.code.org)

Standard Rails application.

• dashboard/config/routes.rb (run rails routes for fullly-rendered route map)
• Uses standard Rails routing and layouts/rendering (see Ruby on Rails Guides for full documentation, e.g., "Routing" and "Layouts and Rendering")

Shared middleware (/shared)

We have several Rack middleware^spec modules that are inserted into both Pegasus (via config.ru) and Dashboard (via application.rb), and provide 'shared' functionality to both web-applications. Some of these middleware apps are their own self-contained Sinatra apps (e.g., FilesApi) that handle their defined routes^example when inserted into the middleware 'stack' for each web-app.