Replies: 3 comments 2 replies
-
Imo there are two pieces to this GovernanceAs you've mentioned we should have a list and the use-cases for the edge workers, and some rules on how/when to use them. One holistic "list" can be found in the Akamai control center, but use-cases and scope are not captured. Based on the akamai edge worker product limitation document we can execute exactly one script per request The workaround is having one edge-worker script just executing more code and enriching the HTML response... however, the impact is increased project-complexity. Questioning EW use-casesI've done a good amount of due-diligence on EWs for performance and would question each and every use-case of edge workers within adobe.com. DC wanted to improve upon some of the performance-tax that comes with additional requests (scripts, utils, utils) however this can be mitigated. If we expect some performance benefits, we should try to raise them with the AEM product team or solve them within the milo ecosystem IMO. There is an increase in complexity with EWs and we need to vet whether this increase in complexity is warranted or can solved differently. We should definitely use them where they make sense, however if we have site-wide spanning EWs that are always on, IMO we should see if there are different paths to solve the problem. |
Beta Was this translation helpful? Give feedback.
-
@npeltier The floodgate edge-workers were hosted here as a POC to setup automated deployments. But there is an issue with automated deployments to Akamai, so the repo has not been updated for few months. Currently the changes are manually handled by updating the EW JS in the Akamai control center directly. You are right about 1 EW per request. When EW is enabled for Floodgate, there cannot be another EW for the same request. In case of DC, there was no requirement to Floodgate the DC pages that have EW setup. So there was no conflict. If EW's are going to be used for any other reason in the near future, the use-cases and overlaps need to be considered. |
Beta Was this translation helpful? Give feedback.
-
right @mokimo, "don't use EW for this" could be part of governance as well, no? for happy few that pass that first gate, assuming there can be more than one use case for a given resource, we could consider the unique EW to be some kind of aggregator of children scripts, no? |
Beta Was this translation helpful? Give feedback.
-
Hey,
last of the excellent milo deep dive sessions was the excellent @Ben-Zahler's team's 'Implementing Access Control on AEM EDS Sites' that - spoiler for those who didn't attend - was presenting so announced access control through edge workers on akamai.
Following up discussion was fruitful and i promised @mokimo the discussion that follows.
If i count correctly atm we have EW (edge workers) for DC inclusion of code in requesting page, floodgate, and above ACs. I'm putting an emphaze on if i count correctly as for now there are no rules / processes / guidelines and people just add them, and to start, there is no way to know where they are. Anyone reading this, if you have usage of them, feel free to chime in with links & docs :)
As the title announces it we would like to rationalize our usage of them, starting by having the complete list, and eventually some docs, maybe later common code, common repo or common subdirectory in repos, rules, etc...
This is something quite urgent to do as:
so yeah, ideas, other use cases, feedbacks, questions, anything is welcome :)
Beta Was this translation helpful? Give feedback.
All reactions