feat(core): Switch client to the CloudFront front door + reuse Hosting's - #513
Draft
Simone319 wants to merge 2 commits into
Draft
feat(core): Switch client to the CloudFront front door + reuse Hosting's#513Simone319 wants to merge 2 commits into
Simone319 wants to merge 2 commits into
Conversation
🦋 Changeset detectedLatest commit: 9002551 The changes in this PR will be included in the next version bump. This PR includes changesets to release 23 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Simone319
changed the title
…'s (D3) Complete the front door (Track D, D3): the client now resolves the front-door origin, and a Hosting app reuses Hosting's distribution instead of provisioning a second one. - Replace D2's eager finalizeFrontDoor with scheduleFrontDoor, which registers a one-shot CDK aspect resolved at synth — after a Hosting construct built past create() exists. Branches: Hosting present → reuse it (no 2nd distribution); no Hosting + provision → create the Blocks-owned distribution; else nothing. - The distribution is scoped under the owning BlocksStack/BlocksBackend so multiple backends in one parent stack don't collide on the construct id. - BlocksStack's ApiUrl output is now Lazy → the front-door origin when provisioned, else the gateway; the deploy script writes it into the client config.json, so the client switch needs no client-code change. - Drop the per-compute frontDoorOrigin seam (added in D2) in favor of a URL contract: httpOriginFromApiUrl centralizes origin construction and Hosting's addApiBehaviors reuses it. Hosting publishes its distribution via registerHostingDistribution. - Deprecate BlocksStack/BlocksBackend gateway + apiUrl (removed in D5). Per-namespace routing to multiple computes and the client's per-namespace path land with multi-compute fan-out (D4). Non-breaking coordinated redeploy.
The comprehensive app hard-pinned BlocksPresets.sandbox in every mode, so the production e2e never ran the production posture and the managed CloudFront API front door (provisionApiFrontDoor, on in the production preset) had no deployed coverage. - index.cdk.ts: production mode now uses BlocksPresets.production, overriding only the teardown-hostile fields (removalPolicy → DESTROY, deletionProtection → false) so CI can still destroy the stack, and keeping the sandbox allowedOrigins so the Node e2e client's cross-origin probes still pass. Sandbox mode is unchanged. - e2e.test.ts: add a production-only assertion that the client resolves the CloudFront front-door origin (config.json apiUrl is *.cloudfront.net, not execute-api). Every other test then runs THROUGH the front door in prod mode by virtue of that resolved URL — including the auth cookie round-trip. Covers the "no Hosting + provisionApiFrontDoor" branch in the right tier (prod e2e), leaving the no-front-door path to the sandbox e2e and the Hosting-reuse path to the hosting-* Playwright suites.
Simone319
force-pushed
the
zimzha/front-door-d3
branch
from
September 8, 2026 13:16
9002551 to
15efcac
Compare
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.
What this does
Completes the front door: the client now resolves the front-door origin, and a Hosting app reuses Hosting's distribution instead of provisioning a second one.
scheduleFrontDoor, a one-shot CDK aspect resolved at synth (after aHostingconstruct built pastcreate()exists): Hosting present → reuse it (no 2nd distribution); no Hosting + provision → create the Blocks-owned one; else nothing.BlocksStack/BlocksBackendso multiple backends in one stack don't collide (a real bug the core suite caught).BlocksStack'sApiUrloutput isLazy→ the front-door origin when provisioned, else the gateway; the deploy script writes it intoconfig.json, so the client switch needs no client-code change.frontDoorOriginin favor of a URL contract:httpOriginFromApiUrlcentralizes origin construction and Hosting'saddApiBehaviorsreuses it. Hosting publishes its distribution viaregisterHostingDistribution.BlocksStack/BlocksBackendgateway+apiUrl(removed in D5).Deferred to D4: per-namespace behaviors, per-compute URLs, the client's per-namespace path.
Testing (this is where the e2e lands)
front-door.cdk.test.ts— prod creates one distribution +ApiUrlreferences it; sandbox none; Hosting present → no Blocks-owned distribution. Core 783, bb-lambda-compute, blocks all green.removalPolicy→DESTROY +deletionProtection→false so CI can tear down, keeping sandboxallowedOrigins). Soe2e-productionprovisions the managed front door, the client resolves the CloudFront origin, and the whole suite — including the auth cookie round-trip — runs through it. Added a prod-only assertion thatconfig.json.apiUrlis*.cloudfront.net, notexecute-api.hosting-*Playwright → Hosting-reuse path (cookie-through-CloudFront).CI note: this PR is stacked on the D2 branch as a native GitHub stack (#514), and the full
pr-checkssuite — including Build, Unit Tests, E2E Local — runs against it, so the front-door e2e runs here. (An earlierpr-checks.ymlbase-branch tweak was dropped: the stack triggers the full suite without it.) Non-breaking coordinated redeploy (no prod traffic yet).