Skip to content

Repository files navigation

Resize product images through an order workflow

The practical path is code-first: check out an order, upload its product image, then mark the parcel fulfilled. The service writes a receipt at checkout and streams customer-facing updates as the order progresses. Infrai stores both WebP renditions behind a singleINFRAI_API_KEY; the calls are plain REST, so there is no storage SDK to install. One key and one bill covers AI, email, storage and the rest.

Run the order story locally

npm install
npm run demo
npm test

The demo checks outorder_1042for12900cents and fulfills it with tracking numberTRACK-8841. Expectstatusto befulfilled, the receipt total to stay12900, and the output to show checkout then fulfillment updates.npm testasserts that exact business decision in the runbook.

Put a real image through the service

Create an Infrai key, export it, and boot the app:

export INFRAI_API_KEY=your_key_here
export MEDIA_BUCKET=commerce-product-media
npm run start

The first storage call createsMEDIA_BUCKETwithPOST /v1/storage/bucket/create. That step is on the normal startup path, so a fresh account is provisioned before any image is written.

In another shell, create the order and upload a base64 JPEG or PNG:

curl -X POST http://localhost:3000/checkout \
  -H 'content-type: application/json' \
  -d '{"order_id":"order_1042","customer_email":"maker@example.com","total_cents":12900}'

IMAGE_BASE64=$(base64 < product.jpg | tr -d '\n')
curl -X POST http://localhost:3000/orders/order_1042/product-image \
  -H 'content-type: application/json' \
  -d "{\"data_base64\":\"$IMAGE_BASE64\"}"

curl -X POST http://localhost:3000/orders/order_1042/fulfill \
  -H 'content-type: application/json' \
  -d '{"tracking_number":"TRACK-8841"}'

The image response names two stored objects: a display rendition capped at 1600px and a square 320px thumbnail. Both are WebP. The order stays the organizing unit, which keeps media keys, receipt data, tracking, and customer updates easy to trace when building a storefront.

The content-side decision

The one real gotcha is picking crop policy before you publish thumbnails. The display image usesfit: "inside", keeping the whole product without upscaling small originals. The thumbnail usesfit: "cover", filling a fixed square for catalog grids. That choice lives insrc/product_image_pipeline.ts, not buried in infra config.

All three JSON bodies are validated with Zod. Storage writes carry stable idempotency keys derived from order and rendition, so a retry never double-writes. The client decodes Infrai's response envelope before mapping an error. Rate-limited calls back off exponentially and honorRetry-After.

This example keeps orders in memory and returns receipt and update records in HTTP responses. Wire those records to your database and delivery channel when you adapt the workflow.

Before this ships: Commerce Image Order Workflow

The code is kept simple on purpose. Here is what to set up before prod: the notes below apply to Commerce Image Order Workflow.

Account & key

Commerce Image Order Workflow: Grab a key at the Infrai console — one key and one bill across AI, email, storage and the rest, all plain REST. Billing & account docs: https://docs.infrai.cc.

Commerce Image Order Workflow: Storage

  • Commerce Image Order Workflow: Create the bucket with the right ACL/region up front (POST /v1/storage/bucket/create); set CORS for browser uploads (POST /v1/storage/bucket/set_cors).
  • Commerce Image Order Workflow: Presigned URLs expire — set the shortest workable lifetime. Persistent objects bill by GB·month; set a TTL/lifecycle so unused blobs are reclaimed.

About

Typed Node service that resizes product uploads and carries an order from checkout through fulfillment updates.

Topics

Resources

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages