As an advanced developer, I would like to extend some parts of the VCL logic

[kptdobe]

@koraa and myself worked both on a way to use the subdomain as the source for the content repo and owner. The use case is simple:

• as a domain owner, I want to offer anyone the capability to hit https://-.mydomain.com:
  • a design (html.htl and html.pre.js) is handled by the domain owner (standard Helix project)
  • / can be defined by any end-user and refer to a git repo with some content.

To achieve that, it is pretty easy to setup an Helix project, deploy and publish. The handling of the / from the subdomain must be done on Fastly in VCL - basically requires a custom helix.vcl which gets overwritten each time by hlx publish thus requires a manual task to patch it in Fastly after each publication. Here is an example of customisation: https://gist.github.com/kptdobe/bd0f5bb10b88783a3cefd917beb98a68

The use case could be achieved in a very simple way if as an advanced developer I have a way to define a custom.vcl file in my Helix project that would be uploaded for me during the publish and that would allow me to extend / override certain pieces of the VCL. Like this, no need to manually patch the helix.vcl file.

For this use case, the extension point could be: a hlx_type_pipeline_ext subrouting is called at the end of the hlx_type_pipeline subroutine. By default it is empty, I would write one that contains the logic to override req.http.X-Owner and req.http.X-Repo based on the use case requirements.

Note 1: this requires advanced VCL knowledges thus it should be reserved to really advanced developers that knows what they are doing.

Note 2: this is the only known extension for now, I would not allow more until we have a concrete and clear use case.

[trieloff]

I think you will need the ability to insert before and after, as some subroutines use return.

[kptdobe]

I started to look into since but I do not feel comfortable doing that. Before changing anything, I'd like to make sure I am taking the right approach. I would do it like this:

helix-publish side:

• in helix.vcl, add a call to hlx_type_pipeline_before and hlx_type_pipeline_after at the end of the hlx_type_pipeline subroutine. We do not need more for now.
• extend the helix-publish action to accept a new parameter: customVCL - string that my contain the VCL extensions.
  • a better approach would be to extend the configuration parameter but it seems that it is 1:1 the helix-config... Feedback ?
• if customVCL is not provided, include the default layouts/fastly/custom.vcl which by default contains the skeleton of all the hlx_type_pipeline_before and hlx_type_pipeline_after subroutines (empty subroutine).
  • I do not think that in VCL you can do "a if function exists, call it, otherwise do nothing". But still need to check. If this is doable, than the including default is not necessary.

helix-cli side:

• during hlx publish:
  • check if a custom.vcl file is present at the root of the project for the current code branch
  • if present, read it and post its content together with the rest as the "customVCL" parameter

Looks relatively simple but I'd like the feedback from the "architects" @tripodsan and @trieloff.

[tripodsan]

a better approach would be to extend the configuration parameter but it seems that it is 1:1 the helix-config... Feedback ?

we could also alter the payload with:

{
  config: { ...helix-config... },
  vcl: {
    custom: "....",
  }
}

i'm sure we need more later :-)

[tripodsan]

check if a custom.vcl file is present at the root of the project for the current code branch

I would make it more explicit via argument, like:

hlx publish --custom-vcl=vcl/custom.vcl

[trieloff]

I agree with @tripodsan on both counts.

[kptdobe]

Here is how to use custom VLC:

• copy https://github.com/adobe/helix-publish/blob/master/layouts/fastly/extensions.vcl into your project (in a folder, does not really matter)
• fill the subroutines with your extensions
• publish now with --custom-vcl property: hlx publish --custom-vcl='<folder>/extensions.vcl

Your extension points are published to Fastly together with the rest of the VCL files.
For now, only the "extensions.vcl" override is supported.