To discuss: bundle AMP Runtime in AMP Optimizer releases

[sebastianbenz]

AMP Optimizer requires a few AMP runtime artifacts to run effectively (validator rules, v0.css,...). Before performing a transformation these need to be downloaded which has a few downsides:

• first transformation is going to take longer
• AMP Optimizer requires an internet connection to work (e.g. doesn't work in development when offline).

To mitigate this Optimizer:

1. downloads artifacts once and will only check for a new version once the max-age has expired.
2. downloads artifacts at install time to ensure that transformations can be performed even when offline.

These two solve the problem mentioned above, but in particular the postinstall step has disadvantages such as #966 + increases the install time.

One way to fix this would be to bundle the latest AMP runtime artifacts with each Optimizer release as fallback instead. The problem with this approach is that runtime artifacts might get outdated and we need to ensure regular (automated with every AMP release?) releases.

[schlessera]

One main difficulty you might be facing when trying to solve the above is that the library should be agnostic to the framework in use, or to the filesystem or cache that are available.

I handled this in the PHP library in the following way:

• There's a folder for local fallback resources in the library that is part of the source repo and version-controlled along with the rest of the library: https://github.com/ampproject/amp-toolbox-php/tree/0.3.0/resources/local_fallback
• There's a script that is run daily by a GitHub Action that synchronizes the fallback files and creates a PR if there was a change. This PR is auto-merged when all checks pass, so it basically kept in sync automatically on a daily basis.
• The transformation engine accepts a remote request helper via dependency injection: https://github.com/ampproject/amp-toolbox-php/blob/0.3.0/src/Optimizer/TransformationEngine.php#L47. This ensures that someone integrating the library can hook it up to whatever abstractions for filesystem and/or cache are needed.
• On the implementation side (in this case, the WP plugin), I have a fallback decorator for the remote request that just goes through all provided remote request implementations until it receives a response it can use. This in turn is decorated with a cached implementation. This particular setup uses the WordPress HTTP abstraction (instead of the default cURL) to do all downloads and use the WordPress cache abstraction to cache remote request responses. These are built in such a way that they respect cache header directives.
• There's a mapping that centralizes the knowledge about what files to use as fallback resources, so that the sync script and the integration to use them are all based on the same source of truth: https://github.com/ampproject/amp-toolbox-php/blob/0.3.0/src/Optimizer/LocalFallback.php

[schlessera]

Oh, the above assumes you want to solve this for having the best of both worlds: a local fallback to ensure the library works no matter what together with dynamic downloads to keep a running system up-to-date.

[sebastianbenz]

Thanks for the input. Your approach makes a lot of sense! I really like the GitHub action based auto update process.