Rebasely Beta: data may be purged

examplesstorefront Public

Concepts

How this repository is built and why: its architecture and its notes, from the .rebasely folder, for people and agents.

Architecture

From .rebasely/architecture/system.yaml at f6403bb: 7 components, 7 connections.

Architecture diagram: 7 components, 7 connections storefront-api to db (d1)storefront-api to images (r2)storefront-api to stripe (https)storefront-api to order-events (queue)stripe-webhook to storefront-api (rpc)stripe-webhook to stripe (webhooks)fulfilment to storefront-api (rpc)d1r2httpsqueuerpcwebhooksrpcstorefront-api: The public HTTP API (wrangler.jsonc, Worker storefront-api). Shoppers browse the catalog, fill carts and check out; the merchant edits products and uploads their images with the admin token. Its OrdersService entrypoint is how the other Workers change orders: it is the only Worker with the database storefront-apiWorkerstripe-webhook: Worker storefront-stripe-webhook (workers/stripe-webhook). Verifies Stripe's webhook signatures and settles the order of each PaymentIntent through OrdersService.stripe-webhookWorkerfulfilment: Worker storefront-fulfilment (workers/fulfilment). Consumes order-events, sends each paid order to the warehouse's shipments API and records the shipment through OrdersService. Failed messages retry with backoff and end in order-events-dlq after six attempts.fulfilmentWorkerdb: The storefront database: products, carts, orders and their lines. Every schema change is a numbered file in migrations/, applied with wrangler d1 migrations apply.dbD1 databaseimages: Bucket storefront-images: product images under products/<product>/<hash>.<ext>. A key is never overwritten, so every image URL can be cached for a year. Public on its custom domain (IMAGES_URL), where browsers load the images; storefront-api only writes to it.imagesR2 bucketorder-events: Queue order-events: order.paid and order.cancelled, sent by OrdersService when an order changes state. Consumed by fulfilment (queues.consumers in its wrangler.jsonc). At least once, so consumers dedupe by order id.order-eventsQueuestripe: Stripe, through the stripe npm package. storefront-api creates a PaymentIntent per order with the secret key; the shopper confirms it in the browser with the Payment Element, and Stripe reports the outcome to stripe-webhook.stripeExternal

Select a component to see what it talks to.

fulfilment

Worker storefront-fulfilment (workers/fulfilment). Consumes order-events, sends each paid order to the warehouse's shipments API and records the shipment through OrdersService. Failed messages retry with backoff and end in order-events-dlq after six attempts.

Owns
workers/fulfilment/**
Talks to
storefront-api (rpc)

Markdown in .rebasely/kb/. Add a folder or a file there to add a note.

storefront knowledge base

How the storefront works and why it is built this way. Start with the concept notes, then read the decisions for the reasoning behind them. The architecture tab has the map of Workers and storage these notes refer to.

Concepts

  • Catalog: products, prices and stock, and how the merchant edits them.
  • Carts: what a cart holds and the limits it enforces.
  • Product images: how images get into R2 and back out.
  • Checkout: how a cart becomes an order, and how stock and payment are handled.
  • The payment webhook: how Stripe's events mark orders paid or cancelled.
  • Order events: the queue that announces paid and cancelled orders.
  • Fulfilment: how paid orders become shipments at the warehouse.

Decisions

Guides

Components

  • The public HTTP API (wrangler.jsonc, Worker storefront-api). Shoppers browse the catalog, fill carts and check out; the merchant edits products and uploads their images with the admin token. Its OrdersService entrypoint is how the other Workers change orders: it is the only Worker with the database binding. A cron trigger expires unpaid orders every five minutes.

    Owns
    src/**
    Talks to
    db (d1), images (r2), stripe (https), order-events (queue)
    Used by
    stripe-webhook (rpc), fulfilment (rpc)
  • Worker storefront-stripe-webhook (workers/stripe-webhook). Verifies Stripe's webhook signatures and settles the order of each PaymentIntent through OrdersService.

    Owns
    workers/stripe-webhook/**
    Talks to
    storefront-api (rpc), stripe (webhooks)
  • fulfilment Worker

    Worker storefront-fulfilment (workers/fulfilment). Consumes order-events, sends each paid order to the warehouse's shipments API and records the shipment through OrdersService. Failed messages retry with backoff and end in order-events-dlq after six attempts.

    Owns
    workers/fulfilment/**
    Talks to
    storefront-api (rpc)
  • db D1 database

    The storefront database: products, carts, orders and their lines. Every schema change is a numbered file in migrations/, applied with wrangler d1 migrations apply.

    Owns
    migrations/**
    Binding
    DB
    Used by
    storefront-api (d1)
  • images R2 bucket

    Bucket storefront-images: product images under products/<product>/<hash>.<ext>. A key is never overwritten, so every image URL can be cached for a year. Public on its custom domain (IMAGES_URL), where browsers load the images; storefront-api only writes to it.

    Binding
    IMAGES
    Used by
    storefront-api (r2)
  • Queue order-events: order.paid and order.cancelled, sent by OrdersService when an order changes state. Consumed by fulfilment (queues.consumers in its wrangler.jsonc). At least once, so consumers dedupe by order id.

    Binding
    ORDER_EVENTS
    Used by
    storefront-api (queue)
  • stripe External

    Stripe, through the stripe npm package. storefront-api creates a PaymentIntent per order with the secret key; the shopper confirms it in the browser with the Payment Element, and Stripe reports the outcome to stripe-webhook.

    Package
    stripe
    Used by
    storefront-api (https), stripe-webhook (webhooks)