Alpha Version: You are viewing the ALPHA documentation. This is an experimental version and may contain breaking changes.
Skip to main content

Test the deployed shop

Once the stacks are up (from Deploy to your AWS account), this page shows how to find the live URLs, sign in, and verify the end-to-end path — including live subscriptions.

Find the live URLs​

The platform stack exports the endpoints. From platform-aws/:

pulumi stack output --stack alpha

Look for the AppSync GraphQL endpoint and the CloudFront URL that serves the host-shell SPA. Open the CloudFront URL in a browser.

Log in against deployed Cognito​

The deployed platform authenticates against the Cognito user pool configured on the deploy page (Step 2). A freshly auto-provisioned pool has no users yet — create one:

aws cognito-idp admin-create-user \
  --user-pool-id <COGNITO_USER_POOL_ID> \
  --username you@example.com \
  --user-attributes Name=email,Value=you@example.com
# then set a permanent password:
aws cognito-idp admin-set-user-password \
  --user-pool-id <COGNITO_USER_POOL_ID> \
  --username you@example.com --password '<StrongPassw0rd!>' --permanent

Sign in to the host-shell with that user and run the same smoke test you ran locally: add a category and product, register a customer, place an order, and confirm read models update.

Seed demo data (optional)​

To fill the views without clicking through by hand, run the demo seed against the deployment. It drives the same public GraphQL command API as locally. The AWS seed targets AWS by construction — run it from platform-aws/:

cd examples/online-shop-hybrid/platform-aws
pnpm run seed

It first asks which data set to seed (full or sample), then picks the stack (one Pulumi stack auto-selects; otherwise it lists the stacks or reads SEED_STACK). It reads that stack's config.json — the same file the host-shell boots from — for the GraphQL and upload endpoints, region and Cognito client (or the stack outputs directly when no host-shell URL is published), then asks which account to seed as.

The accounts it offers come from .reventless/users.yaml beside the platform (the file that records what was created in the pool), listed in the order the file defines them with the first as the default; it holds the password too, so there is nothing to type. Each must exist in the pool with a permanent password, per the previous section. SEED_USER picks one by username or 1-based index, and SEED_USERS_FILE points at a file elsewhere. Without such a file the seed asks for a username and password instead.

Set SEED_SET (full or sample), SEED_STACK (the stack name), plus REVENTLESS_DEMO_USER/REVENTLESS_DEMO_PASSWORD for a non-interactive (CI) run — that pair bypasses the accounts file, so CI needs no copy of it. The seed is non-idempotent — run it against a fresh deployment, not on top of existing data.

Skipping image uploads. SEED_SKIP_UPLOADS=1 seeds the domain data without uploading product images (imageUrl is left empty) — use it when the deployment serves no upload endpoint, or to seed fast. This is the reliable knob: an empty REVENTLESS_UPLOAD_ENDPOINT reads as "unset" and falls back to discovery, so set SEED_SKIP_UPLOADS rather than blanking the endpoint.

Pulumi backend. This example is deployed by CI to Pulumi Cloud, so its SeedAws.res pins the backend to https://api.pulumi.com — the seed reads the stack from there regardless of which backend your CLI is logged into (needs a Pulumi Cloud login / PULUMI_ACCESS_TOKEN). A self-hosted platform instead pins its own store, e.g. ReventlessSeedAws.connect(~backend="s3://<bucket>?region=<r>", ()) (needs ambient AWS creds). SEED_PULUMI_BACKEND overrides the pin; omit it to use the ambient login. The pin is passed as PULUMI_BACKEND_URL on a copy of the environment, so your persistent pulumi login is never changed.

Verify subscriptions end to end​

The example ships a verification script that drives a command and confirms the change is pushed over a WebSocket subscription — the AWS equivalent of watching the live view update in the local UI. It exercises the live-update path:

AddProduct command → DynamoDB write → DynamoDB Stream → StateTopic Lambda
                   → AppSync Events API → WebSocket subscriber

Run it from platform-aws/:

cd examples/online-shop-hybrid/platform-aws
node verify-subscriptions.mjs

Requirements:

  • AWS credentials with appsync:EventPublish, appsync:EventSubscribe, and appsync:GraphQL.
  • The Pulumi stack deployed.
  • Update the config block at the top of verify-subscriptions.mjs — the AppSync host and API IDs there point at the reference stack. Replace them with your values from pulumi stack output before running.

A successful run publishes an AddProduct, subscribes over the WebSocket, and confirms the resulting event arrives at the subscriber.

What you've proven​

The deployed application runs the identical plugin code you tested locally — now on real AWS infrastructure (DynamoDB, Lambda, SQS, AppSync, CloudFront, Cognito), with live subscriptions flowing through the StateTopic Lambda to WebSocket clients.

Where to next?