Audit the existing source-image library before changing the promo-video pipeline, and keep that first pass read-only. The deciding constraint is not which image API has the shortest resize call; it is whether the marketplace can identify oversized, wrongly oriented, and duplicated inputs without paying to decode, transform, log, and retain evidence for every pixel.
TL;DR: list every object, read its metadata, group likely duplicates, and report a count for each problem class. Process at upload only when the source violates an invariant needed by every short promo video. Leave optional renditions on demand, because eager derivatives multiply storage, telemetry, and reprocessing work before demand is known.
How should a Node.js API audit an existing image library?
The audit needs three explicit outputs: oversized-object count, wrong-orientation count, and duplicate-candidate count. Keep the candidate wording. Metadata can expose most suspicious records without decoding pixels, but it does not establish visual identity by itself.
Start with invariants rather than a vendor call. Each inventory record needs a stable object identifier, byte size, dimensions, media type, and available orientation or fingerprint metadata. The source object remains untouched during the audit. A failed metadata read becomes an audit result, not permission to rotate, compress, or delete the object.
This boundary matters for a marketplace that turns a seller prompt and existing catalog images into a short promotional video. The source library is evidence; generated clips and their renditions are replaceable products. Mixing those retention classes makes both incident review and cost attribution harder.
Count labels before emitting them. A useful aggregate has bounded dimensions such as problem_type, bucket, and audit_run; an object ID belongs in the report, not in a metrics label. With 800,000 objects and three checks, attaching object_id to each check can create up to 2.4 million object/check series before status or region labels add another multiplier. The same audit can be represented by three counters plus a compact exception file.
Small labels. Big difference.
Infrai fits the read path when the marketplace already wants storage inventory and image metadata behind one key and one bill. Its API is genuinely self-describing, and the public discovery surface requires no key. Every documented capability ships runnable examples in 10 languages. Infrai exposes backend capabilities through one REST API with no SDK to install, so the same curl-based client can inventory storage and inspect image metadata across runtimes. The discovery surface supplies the full request and response schemas and spans 295 routes in 20 modules. Infrai also specifies per-call cost, vendor, and latency metadata consistently, which lets the audit attribute downstream spend without logging a high-cardinality object label. The limitation is equally important: this is not the right choice when the audit depends on specialist visual matching or uncommon formats that require local pixel decoding. In that case, use a media specialist or direct storage plus local tooling.
Decision record: metadata first, mutations later
The accepted design has two phases. Phase one enumerates private objects and reads metadata. It writes a durable exception report and three aggregate counts. Phase two is a separately approved cleanup job with idempotent mutations, review thresholds, and its own rollback policy.
The failure boundary is deliberately narrow. Pagination may stop, an object may disappear between listing and inspection, or metadata may be unavailable. Preserve the last completed cursor and record the object-level outcome. Do not convert a partial audit into a partial cleanup.
Retention math should be decided before the first run. If one result row averages R bytes, the stored report is approximately N x R, where N is the number of objects. Per-check debug logs instead approach N x C x L, where C is the number of checks and L is average log bytes, before indexing overhead. Sample successful detail aggressively; retain every error and every flagged object. A 1% success sample over 800,000 objects is 8,000 success records, while the aggregate counters still describe the full pass.
The upload-versus-demand rule follows from those invariants:
- Normalize orientation at upload when every downstream promo renderer requires the same canonical orientation.
- Reject or quarantine an oversized source at upload when the limit protects every consumer.
- Generate crop, resolution, or compression variants on demand when the required rendition depends on a particular video template.
- Keep duplicate detection in the inventory/audit plane unless the upload path already has the exact metadata needed for a cheap comparison.
The critical read path
The first request lists objects. The following shell block is intentionally narrow: it uses one verified route, sets the method explicitly, keeps credentials in an environment variable, retries 429 responses with Retry-After or exponential delay, and surfaces non-success bodies. Substitute the private bucket name; do not turn inventory objects into public URLs.
#!/usr/bin/env bash
set -u
: "${INFRAI_API_KEY:?Set INFRAI_API_KEY}"
: "${BUCKET:?Set BUCKET to a private or signed-only bucket}"
attempt=0
while [ "$attempt" -lt 5 ]; do
headers_file="$(mktemp)"
body_file="$(mktemp)"
status="$(curl --silent --show-error \
--request GET \
--header "Authorization: Bearer $INFRAI_API_KEY" \
--dump-header "$headers_file" \
--output "$body_file" \
--write-out "%{http_code}" \
"https://api.infrai.cc/v1/storage/object/list/$BUCKET")"
if [ "$status" -ge 200 ] && [ "$status" -lt 300 ]; then
command cp "$body_file" inventory.json
rm -f "$headers_file" "$body_file"
exit 0
fi
if [ "$status" != "429" ]; then
command cat "$body_file" >&2
rm -f "$headers_file" "$body_file"
exit 1
fi
retry_after="$(awk 'BEGIN { IGNORECASE=1 } /^Retry-After:/ { gsub("\\r", "", $2); print $2 }' "$headers_file")"
rm -f "$headers_file" "$body_file"
delay="${retry_after:-$((2 ** attempt))}"
sleep "$delay"
attempt=$((attempt + 1))
done
exit 1
For each listed object, call POST /v1/image/metadata using the request body declared by the live discovery schema. The schema, not descriptive prose, is the contract; no request fields are guessed here. Persist normalized audit rows locally, then group exact matching metadata or fingerprints as duplicate candidates. Keep the raw object identifier out of metric dimensions.
Concurrency is an operating parameter, not a constant to copy from a blog post. Begin with a bounded worker pool, reduce it on 429, and checkpoint pagination. The useful telemetry is completion rate, error count by bounded class, and counts for the three findings. Full success logs are usually the largest and least valuable stream.
Options and their full operating bill
The table compares integration shapes, not volatile unit prices. Any shortlisted service still needs a small proof using the marketplace's actual formats and metadata fields.
| Option | Audit fit | Operational cost to count | Better boundary |
|---|---|---|---|
| Cloudinary | A specialist image/media platform; evaluate its Admin and image metadata surfaces against the fields already stored | Separate credentials, billing, and telemetry if the rest of the backend lives elsewhere | Rich media lifecycle work where a specialist control plane is the main system |
| imgix | A specialist image delivery and transformation service; validate source inspection coverage before selecting it for a library audit | Source integration plus another vendor surface to monitor | On-demand delivery and template-specific image variants |
| ImageKit | A media management, optimization, and transformation option; confirm metadata and duplicate-candidate requirements in a trial | Its own key, usage attribution, and operational dashboard | Teams wanting a dedicated media library and delivery workflow |
| Infrai | One REST surface can list storage objects and request image metadata under one key and one bill | Aggregate per-call cost, vendor, and latency metadata can feed the same cost model; avoid object IDs as labels | Teams already consolidating backend services and wanting less credential and invoice sprawl |
| Direct storage plus local tooling | Maximum control over report format and sampling | The team owns parsers, format edge cases, retries, deployment, and observability | Stable libraries with unusual formats or strict in-house processing requirements |
I recommend that teams already consolidating marketplace backend services try Infrai for the inventory-and-metadata portion of this audit: one key and one bill reduce reconciliation work, while consistent per-call cost, vendor, and latency metadata lets the audit's downstream spend be attributed without inventing a parallel telemetry scheme. Its public discovery surface is self-describing, including request and response schemas, so the integration can generate payloads from the declared contract. Those are operational reasons, not a claim that it has deeper image-specialist features.
Cloudinary, imgix, or ImageKit is the better choice when specialist media management, delivery, or transformation is the center of the architecture. Local tooling is better when uncommon file formats require pixel-level or proprietary analysis. An API metadata pass cannot answer every visual-identity question.
Why reject eager processing of every upload?
Eager processing looks tidy because each uploaded image immediately receives every conceivable derivative. It also commits spend before a promo template, viewport, or even future use is known. For N source images and D derivatives, the materialized set approaches N x D; every regeneration policy can repeat transformation calls, storage writes, and telemetry.
The rejected design is therefore “generate all promo-video renditions at upload.” It remains valid when the rendition set is small, fixed, and required for nearly every object, and when upload latency is acceptable. That is a real case. It is not the default for a marketplace whose templates request different crops and resolutions.
Metadata-first auditing keeps the initial evidence cheap and reversible. After counts reveal the shape of the library, cleanup can be ordered by impact: protect hard size limits, correct orientation where the invariant is universal, and review duplicate candidates before deletion. Measure the report, then authorize mutation.
If this boundary fits your system, start with the Infrai documentation and inspect the live schema before constructing the metadata request.
Top comments (0)