Server Rendering of Fragments?

[3ch023]

Related ticket

https://jira.corp.adobe.com/browse/MWPW-154124

Question

Would it be possible to have a page containing several fragments rendered server-side by JS in CloudFlare worker and cached?
Did anyone research/implement something similar? (I think I heard of DC doing some feature with CF workers)

Context

We have a Catalog page containing 93 Card fragments (27 loading initially). To improve the performance, instead of loading fragments separately, we use the EDS index to get Cards content in one request.
The issue with the index is that it's only available on Publish, so GWP can't preview the changes done to cards.

There are several options we consider in order to address it, but one of the ideas was to have a collection page with all the fragments rendered on the server and cached and use it instead of EDS index.
sample collection: https://main--cc--adobecom.hlx.page/drafts/mariia/catalog/catalog-container/collection

[npeltier]

to add to what @3ch023 is saying, this would obviously brings constraint to have to publish container of the fragment to invalidate the cache (not sure if publishing unmodified document does actually invalidate something) but could still be worth it in our case

[drew-cottrell]

No comment on the specifics of your idea, but at a high-level curious what it means to have one implementation for preview and a completely different implementation for publish? In such a case, would testing on preview give us high confidence that the same would work in publish? What precisely would QE/QA be signing off on for preview, just some basic content and not full page functionality? It gets troublesome when we have cases where a test case fails in preview, but then we say "it will work in production the root cause is something that doesn't happen in production". Or vice versa, a bug appears in production but we can't really validate a fix in preview because it works very differently.

[npeltier]

In that case the only difference between publish & preview would be that one is cached, and the other is not, which is basically the case for anyting hlx.live vs hlx.page

[TsayAdobe]

DC team uses Akamai EdgeWorker, not Cloudflare worker. We put scripts.js, styles.css, and CSP into the HTML to speed up the loading.

[sukamat]

@3ch023 I had discussed this with @npeltier in one of the meetings this AM. Adding it here as well.

One potential option for what you are trying to do is using the Akamai EdgeWorkers (EW). With EW, when your page is requested, you will be able to parse your HTML, fetch all the fragments, embed it into your page and then serve the page. That said, fetching 93 fragments in EW might have potential pitfalls, eg: performance, at least on the first hit after cache-invalidation. Subsequent requests should be performant given that the page is cached in Akamai. There will be additional setup required for EW to not perform the tasks on every request (by setting TTL, cache headers etc.).

Alternatively, a script can be written that can perhaps be called based on some trigger or at regular intervals that generates the desired HTML with embedded fragments and posts it to the cached location of Akamai. There used to be a SFTP option before to access/update cached data. Not sure if that still exists. Someone from WebPS might be able to chime in on that one.

[sharmrj]

We (@bandana147, @suhjainadobe, and I) are working on something in the same ballpark, so we've done research on something similar to this (somewhat different usecase).
It should be relatively simple to inline fragments in your HTML on the edge using the HTMLRewriter API. It's already been pointed out that your bottleneck will be network requests (and with 93 you're virtually guaranteed to hit one or more long tail, think P99, latencies), but you could mitigate this with the stale-while-revalidate header.
As an alternative you could look into caching the fragments on the edge with Durable Objects. The linked page indicates a storage limit of 50GB, a key size of 2KiB, and a value size of 128KiB. From a cursory look at a few of our pages each fragment is 1-2KiB (compressed; we can store them as blobs on the edge) and only very rarely higher than that. This way we need only invalidate individual fragments that are republished/previewed rather than the whole page (as I mentioned before, the actual inlining with the rewriter API should be relatively cheap). The question then becomes how many fragments can or should we keep in memory before it becomes too unwieldy to be viable (sort of like an L1 cache for fragments. An L2 cache could be a database)

[honstar]

The existing solution on the live side is leveraging the OOTB EDS index, backed by an excel sheet.

For the preview side of things, I'd suggest looking into standing up a preview index instead of going the Edge Worker route. Here's a rough outline of the proposed solution:

• enable project's github repo to receive events from EDS for the following events: resource-previewed and resource-unpreviewed
• as part of event payload, read path of previewed resource on sharepoint
• extract elements to be indexed and write this to a custom preview index excel sheet on sharepoint
• on the milo block side, implement a switch between preview and live index as data source

By introducing a custom preview index, we don't need to change the existing content logic on the Milo block side.