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.
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.
The MVP will consist of the following:
Hard-coded locale-based aliases and path mappings. Will only work for 99designs.tlds. Deal with it.
- Backends can be HTTP/S for the MVP, later FastCGI will be supported.
Accept-Languageand GeoIP based redirect to the canonical domain based on config
- Backends get an
X-Grout-Localeheader set (and X-Grout-IpCountry)
- Backends get an
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