feat: answer the beacon's collection path at the edge - #108
Merged
Conversation
`BeaconPath` adds a cache behaviour to a distribution the consumer already owns and attaches a CloudFront Function to it at viewer-request. The function returns a 204 and the request stops there, ahead of the cache and ahead of the origin. CloudFront still records it in the access log, and that record is the beacon event. #99 chose the function over a cached object on three things beside cost. The construct ships on its own whatever the distribution serves, a flood of beacon requests stops at CloudFront, and the cache hit ratio stays a measure of the site rather than of the beacon. CloudFront Functions are priced per invocation, at $0.10 per million, and a viewer-request function runs on every request the behaviour matches. A million beacon events is ten pence in invocations, on top of the CloudFront requests and the log delivery a cached object would pay anyway. The cache policy defaults to the managed `CachingOptimized`, which keys on the path alone. Nothing is cached at the path while the function answers it, and the policy is what the path falls back to if the function is ever removed. The function source is a `.cff.js` file so that the oxlint plugin @kensio/yulin ships can hold it to the JS 2.0 runtime restrictions. `pnpm build` copies it into `dist/cdk/` and `pack-check.sh` checks it reaches the tarball. Two Yulin gaps came out of the tests and are raised upstream as KensioSoftware/yulin#1130 and KensioSoftware/yulin#1131. The cache policy and the function's runtime are read off the synthesised template until they close.
|
Warning Review limit reachedNext included review available in 44 minutes. View limit detailsLimit details: You’ve used the included review currently available. Your 90 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (10)
Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
BeaconPathadds a cache behaviour to a distribution the consumer already owns and attaches a CloudFront Function to it at viewer-request. The function returns a 204 and the request stops there, ahead of the cache and ahead of the origin, while CloudFront still records it in the access log. That record is the beacon event, carrying its payload incs-uri-query, and it lands in the same objects, partitions and table as every page request. The cache policy defaults to the managedCachingOptimized, which keys on the path alone. CloudFront Functions are priced per invocation at $0.10 per million, so a million beacon events costs ten pence on top of the CloudFront requests and the log delivery a cached object would have paid anyway. The function source is a.cff.jsfile so that the oxlint plugin @kensio/yulin ships can hold it to the JS 2.0 runtime restrictions,pnpm buildcopies it intodist/cdk/, andpack-check.shchecks it reaches the tarball. Two Yulin gaps came out of the tests and are raised upstream as KensioSoftware/yulin#1130 and KensioSoftware/yulin#1131, so the cache policy and the function's runtime are read off the synthesised template until those close. One measurement is still open and changes none of this: the CloudFront documentation enumerates nox-edge-result-typevalue for a response a function generated, anddocs/beacon-path/says to read it off a deployed distribution rather than guessing.Resolves #99
Conventional commit message, used as the title
Conventional branch name, like
feat/concise-descriptionFull check with
pnpm run checkpassedRebased off latest main
User-facing behaviour is documented in
docs/See https://www.conventionalcommits.org/en/v1.0.0/