washpost/fusion-origin repository overview

⁠Origin

The Fusion Origin is the point of entry for Fusion requests. It is an nginx proxy that supports multiple modes for servicing Fusion requests.

⁠Architecture

⁠Upstream Dependencies

Local Development

In development mode, Lambdas are wrapped and ran locally inside a Docker container, so the upstream dependencies are:

• engine Docker container
• resolver Docker container
• PageBuilder Admin

The PageBuilder Admin is not necessary to run Fusion locally, but it is necessary to perform any configuration of Pages/Templates or Resolvers.

Production Dependencies

The Fusion Origin proxies to:

• engine Lambda
• resolver Lambda
• S3 cache for pre-generated HTML
• PageBuilder Admin (see PB_ADMIN environment variable)

⁠Operations

The Fusion Origin is a multi-tenant proxy that is deployed in each VPC.

For each VPC, there are two environments:

They are deployed as separate ECS services configured in nile.yml⁠.

⁠Environment Variables

IS_PROD

If the origin is running with IS_PROD set to true, then the origin will spawn multiple virtual servers running in the same nginx instance to handle different cache modes (none, allowed, preferred, or update).

Otherwise, the origin will run in local mode.

PB_ADMIN

If PB_ADMIN mode is set, this nginx instance allows PUT/POST requests and proxies back PageBuilder Admin API requests.

By default, PUT/POST requests are disabled and PageBuilder Admin traffic is disabled for security purposes.

⁠Cache Modes

The Fusion Origin supports multiple cache modes which allow for different disaster recovery or failure scenarios.

⁠none (Default)

None is the default cache mode. It means that Fusion makes no attempt to read from or write to cache, so the rendering latency is subject to cold start times.

⁠allowed

Allowed mode will always invoke Lambda, but will fail to S3 cache. The use case for this is to serve static HTML in the event there is an AWS Lambda failure.

This type of disaster recovery requires the generated HTML for rendered articles to be saved to S3 when content is published (see update mode).

⁠update

Update mode will always invoke Lambda, but once the HTML is generated, the engine will persist it to S3.

This mode should be used by internal consumers (such as cache clearing services) when content is published or updated. This will force the engine lambda to update the HTML in S3, which can be used as a backup for disaster recovery scenarios.

⁠preferred

Preferred mode will check S3 for static HTML first. If it does not exist, it will invoke AWS Lambda to render the HTML.

This mode should be used by high traffic websites to reduce the number of AWS Lambda invocations. It should be used in conjunction with update mode to ensure that the static HTML on S3 is always up to date.