Skip to content
This repository has been archived by the owner on May 14, 2020. It is now read-only.

Component-level integration #6

Closed
thewilkybarkid opened this issue Mar 24, 2020 · 7 comments
Closed

Component-level integration #6

thewilkybarkid opened this issue Mar 24, 2020 · 7 comments

Comments

@thewilkybarkid
Copy link
Contributor

thewilkybarkid commented Mar 24, 2020 •
edited
Loading

The header and footer is shared across all the pages, and duplicating it is hard.

Two approaches:

  1. Expose data that is used in the pattern

    Means the rendering, and assets, of the pattern is done by the page-service. Would be complicated to make flexible etc.

  2. Expose the rendered pattern

    Means the HTML, CSS, JS etc is rendered by the component service and is then embedded in the page-service. Means that it's easy to make changes without individual page services having to care (Want a custom footer? Just replace the footer service).

    This is method that has been tried. (At the code-level, rather than a simple server-side include.)
@thewilkybarkid thewilkybarkid mentioned this issue Mar 24, 2020
Closed
@giorgiosironi giorgiosironi mentioned this issue Mar 24, 2020
Closed
6 tasks
@thewilkybarkid
Copy link
Contributor Author

In the experiment currently, the components are complete documents where the head and body are transcluded into the page separately. This allows metadata (eg a stylesheet) to be included too (refs #3 (comment)).

This is rather custom though. Using ESIs could be a lot simpler (using nodesi if not behind a trusted proxy, detected by a Surrogate-Capability request header). However, these are then document fragments. So there can't be any CSS/JS attached.

@thewilkybarkid
Copy link
Contributor Author

We could rely on the page containing the CSS/JS for the component, so the markup is completely decoupled. Awkward if you want to replace it entirely.

Or we could use a second ESI, so there's one in the <head> and one in the <body>.

@davidcmoulton
Copy link
Member

davidcmoulton commented Mar 24, 2020 •
edited
Loading

I favour the two ESI approach over the single ESI approach to maintain the relationship between the HTML and its related CSS / JS etc.

@thewilkybarkid
Copy link
Contributor Author

thewilkybarkid commented Mar 24, 2020 •
edited
Loading

We know Fastly supports ESIs; seems that KeyCDN does and CloudFlare can too.

AWS CloudFront, Google CDN and Azure CDN don't. You'd have to rely on the app-level, or run a local Varnish. (Lambda@Edge doesn't give you access to modify the response body.)

@giorgiosironi
Copy link
Member

You'd have to rely on the app-level, or run a local Varnish.

Also if there isn't a CDN available, which seems a supported use case.

@thewilkybarkid
Copy link
Contributor Author

Happy to say the 2-ESI approach seems good enough?

@giorgiosironi
Copy link
Member

Yes, assuming any possible parameter can be passed in to both if needed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@giorgiosironi @thewilkybarkid @davidcmoulton