search

libero / publisher-micro-frontend-experiment

https://github.com/libero/publisher/issues/371
MIT License
0 stars 0 forks source link

Component-level integration #6

Closed thewilkybarkid closed 4 years ago

thewilkybarkid commented 4 years ago

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 commented 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.

thewilkybarkid commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

giorgiosironi commented 4 years ago

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