ampproject / ampproject/amppackager

ITI: Javascript Implementation of AMP Cache Transformer

Open
#449 5 comments 2 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
141
Forks
46
PR merge metrics
No merged PRs in 30d

Description

# Summary

The current Google AMP Cache requirements effectively mandate a specific implementation of the AMP transforms (the AMP Packager, currently written in Go). We’d like to create a standalone, JavaScript version of the transforms that could be used with any available SXG packaging logic.

# Motivation

By introducing a standalone package, this would decouple the logic of the Google AMP cache transforms from that of the signed exchanges. This would introduce a new level of flexibility, and allow for wider adoption of the technology.

Additionally, a javascript version of the AMP cache transforms would integrate much more seamlessly with existing web pipelines, without requiring a standalone external service. Javascript would allow us to implement these transforms as a final step in our web server, which renders AMP for users.

There currently exists a subset of these transforms already written in JavaScript, in the AMP Toolbox → Optimizer repo. These are not fully complete, however,

# Design

The main requirement is to ensure a way of keeping the JavaScript and Go versions in sync. The actual implementation will dictate a lot of the difficulty - we would need to set up some form of shared testing infrastructure that ensures any changes made to one version gets reflected in the other.

We see three main paths forward in terms of where this implementation will live:

1. Within AMP Packager
2. Within AMP Toolbox → Optimizer
3. As a standalone repo

  | Pros | Cons
-- | -- | --
AMP Packager | Single source of truth for code and logicEasier to create a shared testing infrastructure | Polluting the same repo with two languages and two implementations
AMP Toolbox | Add on to the existing AMP transformsLeverage existing work and framework for adding new transformsAlready implemented and used by industry | Expands scope of existing toolsetHarder to keep implementation in sync with AMP Packager
Standalone Repo | Might be the right level of abstraction for a new codebaseDoes not affect technical direction of the AMP toolbox library | Harder to keep implementation in sync with AMP Packager
Standalone Repo + Go Cache transforms | Single source of truth of transformsBest of both worlds between a standalone repo and having the code live in AMP packager | Requires splitting up the AMP packager repo

We believe that having the code live in the AMP Packager repo is the best way forward, although we are open to a discussion. Sharing the code in the same repo will have the highest likelihood of making sure the versions are in sync, and is the easiest way to set the tests up in such a way that they can be shared.

We could also split the AMP Packager, such that the Go and Javascript versions of the transforms live in their own “AMP Transforms” repo, and the AMP Signed Exchange live in separate repos.

We are open to options depending on which direction the AMP packager maintainers prefer.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the existing Go AMP transforms in AMP Packager and the partial JavaScript transforms in the AMP Toolbox Optimizer. Determine where the JavaScript implementation should live and how shared tests can keep both versions synchronized. Done means a complete standalone JavaScript transform implementation with shared coverage against the Go version.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, javascript
Domain
backend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.