Skip to content

HTTP request lifecycle

suresh edited this page Sep 7, 2021 · 3 revisions

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.)

Other "front door" domain names to code.org served by our main web application (pegasus & dashboard):

  • studio.code.org
  • advocacy.code.org
  • hourofcode.com
  • codeprojects.org

All of the above domain names are configured in Route53 to resolve to the IP addresses of CloudFront Distributions.

CDN / load-balancer

Each CloudFront Distribution has multiple Origins configured. The most important Origin typically is a DNS name that resolves to an AWS Application Load Balancer (ELBv2).

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)

This ERB logic generates VCL that decides whether to route an HTTP request to dashboard or pegasus.

Note that the Ruby HTTPCache class generates a hash that is used to generate CloudFront Behaviors, Varnish VCL, and Rack middleware logic that all implement the same HTTP routing/cache rules for different types of environments.

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:

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

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

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

Standard Rails application.

Shared middleware (/shared)

We have several Rack middlewarespec 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 routesexample when inserted into the middleware 'stack' for each web-app.

Clone this wiki locally