Closed thewilkybarkid closed 4 years ago
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 https://github.com/libero/publisher-micro-frontend-experiment/issues/3#issuecomment-603151062).
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.
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>
.
I favour the two ESI approach over the single ESI approach to maintain the relationship between the HTML and its related CSS / JS etc.
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.)
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.
Happy to say the 2-ESI approach seems good enough?
Yes, assuming any possible parameter can be passed in to both if needed.