This document outlines the lifecycle of a backend a request on the Vanilla platform, from CDN to web server, to response.
CDN / Cloudflare
On Vanilla Cloud every requests request starts in Cloudflare. Here one of a few things may happen:
- Request may be blocked by rate-limiting rules.
- A cached response may be found and returned immediately. Notably Cloudflare's cache does not respect the
vary header, so the only differentiators for this cache are:- Users with session cookies bypass this cache layer.
- Different URLs have different caches.
- Cloudflare will pass the request along to Vanilla's load balancers.
Cloudflare will also resolve SSL certificates for independent domains at this point.
At this point cloudflare will also append a rayID to the request which is used in logs to be able to trace a request/response through each layer.
Load Balancer / HAProxy
Requests are then forwarded to HAProxy. Vanilla's HAProxy cluster will determine which site the request is for based on the host in the request. The correct cluster for the site will be determined and the request will be forwarded to an application server on that cluster.
Application Server / Nginx
At this layer one of 3 things may happen based on the path of the request.
- If the path is blocked for security reasons a 403 will be returned.
- If the path points to a static asset in the
vanilla application that static asset will be returned. - Otherwise the asset will be forwarded into a
php-fpm process using FastCGI.
Application Server / PHP-FPM
At this point Vanilla's PHP backend begins executing, starting from the /index.php file.
Entry point - index.php
Responsibilities:
- Configure error reporting.
- Load environment (including composer autoloader).
- Bootstrap the application.
- Start the dispatcher and dispatch the current request.
Bootstrapping the application
Responsibilities:
- Create and apply core rules for the DIC (Dependency Injection Container).
- Load the configuration.
- If a site is not not configured redirect to the application setup.
- Start addons.
- Make addon classes available in the autoloader.
- Apply addon config defaults.
- Apply addon DIC rules.
- Bind addon event handlers.
- Start authenticators.
- This will construct a Session instance based on cookies for the current request.
- Apply shutdown functions.
- End of request logging.
- Running any scheduled jobs. (after the response has been sent the client).
Running the Dispatcher
This is where the bulk of the actual application code runs.
Vanilla has 2 dispatchers. Garden\Web\Dispatcher (the new one) and Gdn_Dispatcher (the old one). The new one runs first and is responsible for:
- /api/v2 endpoints.
- Newer react-based pages.
If the new dispatcher doesn't match any route, then the request will be passed to the old dispatcher and it will attempt to route the request to a Gdn_Controller.
This can be some of the most dynamic control flow in Vanilla. After this figuring out where a request progress is just a matter of following method calls. To determine where a request is going, follow this documentation.