Repo-less/Helix 5 Architecture

[trieloff]

See https://cq-dev.slack.com/archives/C9KD0TT6G/p1679526644746669

What does Repo-Less mean?

1. You don't need to create a new GitHub repository in order to create a new Franklin site.
2. We invert the pointer from GitHub (through fstab.yaml) to Sharepoint/GDrive, so that Sharepoint/GDrive (through .config/config.xlsx) points to a GitHub repository instead
3. URLs will be https://<branch>--<contentbusid>.hlx.page
4. Changes made to a single GitHub repo can now affect many live sites (fun! but also: scary!)

Why do you call it Helix 5?

It is the next step in Helix' Architectural Evolution

1. Helix 1 – a bring-your-own (Adobe I/O) runtime framework-driven approach that would allow server-side customization
2. Helix 2 – a software as a service that relies on client-side customization
3. Helix/Franklin 3 – a software as a service with superior availability and performance with the same feature set as Helix 2
4. Franklin 4 - a dual-stack architecture that refines Franklin 3 for greater performance and availability
5. Helix 5: Repo-less

What other (breaking changes) are included?

• We drop the name helix from places where it is not needed, e.g. the .helix/config.xlsx file becomes .config/config.xlsx, the helix-default sheet becomes the publish-default sheet, etc.
• We use shorter ContentBus IDs
• Forks no longer work out of the box

What about backwards compatibility?

Existing repositories will be grandfathered, i.e. we won't break any production URLs, but upon launch of Helix 5, no new ref--repo--owner.hlx.page URLs will be supported (no new owner and repos, to be specific). For existing sites, --repo--owner will be a proxy to --contentbusid, so that production traffic will still work as before.
Any changes to fstab.yaml after the switchover date will require a change to the new hostname format.

[tripodsan]

how to deal with multiple mountpoint per fstab?

the content-config points to a owner/repo/ref that contains an fstab that refers the content back at a specific mount root

[tripodsan]

I think the fstab/content is a chicken/egg problem. see below where do we store the mount URL

[tripodsan]

how to deal with partial content that does not (can not) have its own config?

for example, mount AEM/Markup content in a subfolder...

[tripodsan]

how to use different content per branch?

URLs will be https://<branch>--<contentbusid>.hlx.page

that would be out of the box...just create a copy of the content and point it to the same owner/repo. then you can use any branch with the other content.

[trieloff]

Multiple mount points/external sources

• I'm not sure we want to add multiple mount points this time
• For AEM (and other non-Sharepoint/GDrive) sources: as long as the .config/config protocol is supported, i.e. an opt-in to an existing repo can be convincingly relayed to helix-admin, we should be fine.

[tripodsan]

where do we store the mapping from contentbus-id to project? e.g. for fastly to read the code-bus

a. edge-dict -> no go.
b. header of a config-file -> requires restart

[trieloff]

I think we have to go (b), even if it's less than optimal, but it would not increase the total number of restarts.

[tripodsan]

where do we store the mount URL of the content provider url(s) ? aka: how does preview work?

1. the sharepoint/google root url is stored in .config/config

2. initialize the project with the admin: POST /init?url=<sharepointroot>
   this validates the root and calculates the contentbus-id and previews the .config/config.xlsx, generates the config.json etc.
   it returns / displays the .page url of the root.

3. preview works similar but using /preview?url=<sharepointroot> or /preview/contentbusid/path.