Grout

Grout is an HTTP-based front proxy that delegates portions of a url path space to other web applications. This allows for a web application to be composed of a collection of micro-services.

Beyond routing based on url, language or ip-based region, Grout provides downstream services with a unique per-request X-Grout-Id and a per-session X-Grout-Session header for simple cross-service sessions.

Motivation

Presently 99designs.com is composed of 2-3 different web applications. Varnish sits in front of these web applications and dispatches requests to the appropriate backend based on some complicated regular expressions and a large chunk of complicated VCL.

This performs well, but is difficult to maintain and test and the caching behaviour of Varnish is no longer utilized. Grout should first and foremost be a routing layer that is very, very fast. Caching is the job of another layer.

Prototype

The MVP will consist of the following:

Configuration

Hard-coded locale-based aliases and path mappings. Will only work for 99designs.tlds. Deal with it.

HTTP/HTTPS backends

Backends can be HTTP/S for the MVP, later FastCGI will be supported.

Routing

Accept-Language and GeoIP based redirect to the canonical domain based on config
- Backends get an X-Grout-Locale header set (and X-Grout-IpCountry)
A path-based routed that dispatches via hard-coded regexes:
- GET /(customer|designer|business)-blog => wsblog.99designs.com
- GET /tech-blog => 99designs-techblog.s3-website-us-east-1.amazonaws.com
- GET /non-profits => 99designs-99nonprofits.s3-website-us-east-1.amazonaws.com
- GET /browse => blue steel
- GET /projects => projects backend
- else, contests backend

Future Considerations (yagni)

Backends can provide routing information (GET /routes.yaml)
SPDY support w/ server push (X-Associated-Content in responses, same as mod_spdy and nginx)
Support for HTTP Strict Transport Security (HSTS)
Throttling / handling of slow clients
CA/TLS between Grout and Backends

lox/README.md