tripodsan
commented
5 years ago I created a test for the hybrid approach: https://github.com/tripodsan/helix-pages-custom/blob/master/helix-config.yaml
using a normal helix-config.yaml and publish it to a fastly service that is dedicated to handle those domains:
- http://test0.experience-adobe.com/index.html (rendering https://github.com/davidnuescheler/helix-test.git)
- http://test1.experience-adobe.com/README.html (rendering https://github.com/davidnuescheler/analytics-2-0-apis.git)
Note that it reuses the actions from helix-pages, this could be a sequence-link instead of the SHA packagename.
The helix-bot could update this helix-config.yaml and the CI could automatically hlx publish the new VCL.
In order to support custom domain mapping, it must be possible to override the subdomain -> repository mapping per custom domain.
there are 3 possibilities: 1) add the lookup table to edge dictionary and modify the VCL lookup code respectively. 2) move the repository resolver to an openwhisk action. 3) create an own fastly service with a 'hard wired' VCL that uses the respective repository.
Where 1) + 2) have the disadvantage that the mapping table needs to be maintained somewhere. the simples would be to have a (text / json) file in the helix-pages repository that gets automatically updated when a new customer is registered. when using 3), we can use fastly to maintain this list.
Then 1) has the advantage that we can use the existing setup and just need to update/generate the VCL when the mapping table is updated. if this table is stored in the repository, this can be done automatically.
And 2) has the advantage that the resolution logic can be performed in a more sophisticated environment. the mapping table (unless stored in a DB) could be deployed inside the action. the mapping table and resolver could be kept in a separate repository. and the resolver action and dispatch action could be joined together with a sequence. this solution is overall more complex and probably more fragile.
With 3), using a dedicated service id for each customer is probably the most robust and might be the best option for upgrading the customer later to helix-proper. however, the management overhead of having many such services just for helix-pages might not justify this.
hybrid) in addition to the above, it is also possible to use the current helix-pages service for the automatic domain mapping, and create new services for the custom domains that bucket customers together. the advantage is a better separation but also brings a more complicated management overhead.
Note: currently, the limit for number of domains per service is 20, which can be negotiated.