I think we should consider moving the gcs cache data outside of podcache since that file often has merge conflicts in a multi-developer project. Should consider choosing a storage method that has fast/efficient serialization and minimizes merge conflicts.

Make it available to developers.

One internal project I've worked on has an asset pipeline that automatically uploads files from Google Drive to Google Cloud Storage, keyed by folder title and folder modification time.

We should:

• Add official support for this type of pipeline to the extension.
• Remove dependency on objectcache.json for files uploaded by the pipeline (auto-uploaded assets generate objectcache data on the server rather than the client, so the cache data can be pulled offline and stored locally in cache files keyed by folder title).
• Add support for locale groups when working with localized assets (so [email protected] will work, where foo is the name of a Grow locale group defined in podspec.yaml)

Filing a stub issue to track this.

Sometimes the backend throws TransformationError when subsequent requests work. We should make the backend retry 1-3 times before giving up to avoid broken builds.

• Images uploaded to GCS buckets and used with this extension should be auto-compressed.
• When an object is uploaded to a GCS bucket it should be compressed with imageoptim/pngcrush/something else automatically prior to being uploaded to Google's image serving infrastructure.

/cc @uxder @micjamking

We should enhance the functionality of this extension with a few new workflow items. The goal of this project is to increase developer efficiency and empower stakeholders to replace and upload images immediately in the staging environment.

Developer changes

First, we should allow developers to refer to Google Cloud Images by an ID. This removes the need for a developer to decide upon or care about a filename in advance. The IDs should be be usable in either YAML or Jinja templates.

Example syntax (open to other suggestions, this overloads the current syntax which is a full bucket path).

image: !google_cloud_image product1.hero.bg
# Where bucket/product1.hero.bg is some identifier decided upon by the developer.

{{google_cloud_image('bucket/product1.hero.bg')}}

These would return a GoogleCloudImage object, say image.

Now, in templates, consistent with current functionality:

{# Returns a URL that serves `bucket/product1.hero` with `=s1440` suffixed. #}
{{image.url(['s1440']}}

The catch, though, is the following: in development and staging, we want the URL to point to the Google Cloud Images backend, which returns a 302 redirect to the correct image's serving_url. In production, we want the URL to point to the production serving URL generated by Google.

We want to do this in order to enable live uploads + replaces in development and staging without having to rebuild the page. Each reupload of an asset would then create a new serving URL in the backend, and the backend would be able to redirect requests in the proxy to the serving URL.

Example in development/staging

{{image.url(['s1440']}}

Renders to ->
https://gci.grow.io/redirect/bucket/product1.hero.bg=s1440

Requests to that URL 302 redirect to ->
https://lh3.googleusercontent.com/UN7taQ_uv67DQ2BO_WAc5i-b_KHPl4hWXQYG9dj_8FesTSruE_k-AyPId2Jc1DujAMP_kFpD413i8T4TK-O_=s1440

This can be achieved by a theoretical new configuration option proxy in podspec.yaml:

preprocessors:
- kind: google_cloud_images
  backend: https://gci.grow.io
  proxy: true
  [email protected]: false

Changes to uploader

We have an incredibly minimal uploader now which simply uploads images to Google Cloud Storage and generates a serving URL for them. We should enhance this uploader to actually store a mapping in Datastore (or GCS - if desired) that will store metadata about the image, so it can be displayed in the UI, and so that we have a mapping of image ID to serving URL.

Some metadata to store:

• Image format
• Image dimensions
• Uploaded time
• Image ID

Changes to UI

At render time (if proxy is true and if the UI tools are on) – we should collect all of the google_cloud_image dependencies so we can produce a UI allowing stakeholders to audit all the Google Cloud Images on a page and have a way to drag and drop replace them.

New UI tool button

Images modal dialog

Hover states in dialog

• If the requested path is suffixed with @{locale}, the system should use the image corresponding to the current document's locale.
• In the absence of a matching @{locale} file, @{locale} should be stripped and the system should use the root image.

Example:

# On /de/page.html ->
{{google_image("/bucket/folder/path@{locale}.jpg").url()}}

# If /bucket/folder/[email protected] exists -> serve it.
# If not -> /bucket/folder/path.jpg

Need to switch the extension over to use the newer Grow extension format as the legacy extension format is deprecated.