Helix Content Proxy
Helix Content Proxy is not a Content Repository
Status
Purpose
helix-content-proxy serves Markdown documents (later JSON tables, too) from data sources supported by Project Helix (GitHub, Google Docs, OneDrive) and applies transparent resolution of an fstab.yaml configuration files, so that all kinds of content can be retrieved just by knowing owner, repo, ref, and path. helix-content-proxy is intended to be used by helix-pipeline, where it will replace the existing logic for fetching external content from Google Docs and OneDrive and behave like a drop-in-replacement to raw.githubusercontent.com.
Limitations
helix-content-proxy assumes ref to be an immutable sha, so use helix-resolve-git-ref before if you need to resolve a branch or tag name. This limitation is intentional to simplify helix-content-proxy and to allow serving content with immutable caching characteristics.
Usage
Try:
curl https://adobeioruntime.net/api/v1/web/helix/helix-services/content-proxy@v1?owner=…&repo=…&ref=…&path=….mdPagination
When requesting a JSON resource, use the limit and offset URL parameters to restrict the results.
Caching
helix-content-proxy is served with following caching settings:
cache-control: max-age=30758400
surrogate-control: max-age=30758400, stale-while-revalidate=30758400, stale-if-error=30758400, immutable
x-last-activation-id: c0f5d3fbbe584a81b5d3fbbe587a81fc
x-openwhisk-activation-id: 9f934cae5e6c482a934cae5e6c182ac3
x-source-location: https://raw.githubusercontent.com/adobe/helix-shared/a909113cb32cc3dea62e4c981ec4e6eac2e6d3e1/docs/fstab.mdcache-control: to keep content cached in Adobe I/O Runtime and byhelix-fetchsurrogate-control: to keep content cached in Fastly (with push invalidation)x-source-location: to allowhelix-pipelineto calculate a source hash for surrogate-key based push invalidation
For more, see the API documentation.
Development
Deploying Helix Content Proxy
Deploying Helix Content Proxy requires the wsk command line client, authenticated to a namespace of your choice. For Project Helix, we use the helix namespace.
All commits to master that pass the testing will be deployed automatically. All commits to branches that will pass the testing will get commited as /helix-services/content-proxy@ci<num> and tagged with the CI build number.