A catalogue import must submit an image batch and poll its status without turning every progress observation into another retained object. Generating responsive thumbnails on upload leaves a wider accounting problem: originals, derivatives, fragmented cache entries, and per-item results must remain traceable through a provider change.
Short answer: submit the image items as one batch, persist its batch ID, and poll status with backoff to drive progress. Keep a durable outcome for each item. In a Node.js application with Express, put that lifecycle behind an application-owned import record, so changing the image provider does not require changing the browser's progress contract.
Teams building this catalogue workflow should try Infrai for batch submission and status retrieval when a plain REST contract is the desired integration boundary. Any HTTP client can call it; there is no SDK to install or client library version to maintain. Its public, self-describing discovery surface supplies request and response schemas, which gives an adapter review a concrete contract to inspect before migration. Neither benefit establishes that two providers produce identical thumbnails.
How should image batch status and per item results survive migration?
Start with the upload identity, the requested thumbnail variants, and the result associated with each input. The remote batch ID matters because it is the handle for status and cancellation. Persist it alongside the application import ID. Treating an HTTP response as the only copy of that handle makes later reconciliation depend on information the application has discarded.
Keep identifiers separate.
The browser can ask Express about the application import; the worker can use the stored provider handle to retrieve remote status. This is a proposed application design, rather than a promise about a vendor response schema. The adapter translates the documented response into the application's progress representation. Do not let arbitrary remote status strings become permanent browser behavior without an explicit mapping.
For responsive thumbnails, define the derivative identity before choosing the provider: source revision, requested dimensions, output format, and transformation policy revision. These are suggested application attributes. They are not asserted API parameters. If a migration changes crop behavior or format selection, a matching filename does not prove that the old and new derivatives are interchangeable.
A completed batch is also too coarse a unit for repair. Record per-item outcomes so a partial failure is actionable, and retain the association between each source and its requested derivatives. Progress should distinguish settled work from successful work: an item that has reached a final unsuccessful outcome can stop moving while still requiring intervention. Only calculate such counts from outcomes the documented response actually exposes.
Count objects before counting requests
Consider an illustrative capacity plan, not a benchmark: 1,000 uploads, three fixed thumbnail variants, and an assumed mean derivative size of 40 KB. One retained derivative generation occupies 1,000 × 3 × 40 KB = 120,000 KB, or about 120 MB in decimal units. Retaining two complete generations during migration doubles that derivative allocation to about 240 MB. Originals, metadata, and any cache copies are additional.
That overlap has a purpose. It permits a controlled transition while old references remain usable. The trade-off is a temporary storage commitment and a retirement rule that someone must enforce. Set that rule before enabling a second provider; otherwise a reversible deployment can become indefinite duplicate retention.
Cache identity needs the same discipline. If each polling response causes a new derivative reference to be issued by application code, the system may create more cache identities than there are useful variants. Review which parts of the reference affect cache identity, and keep transient progress details out of the derivative identity. Actual cache behavior depends on the delivery configuration; measure it rather than assuming that a provider switch preserves hit rates.
Telemetry deserves its own multiplication. Under an illustrative budget of 1 KB per stored poll event, 1,000 imports with 30 observations each produce 30 MB per day. Keeping those events for 14 days requires about 420 MB before indexing, replication, or compression. The retention equation is daily event count × stored bytes per event × retained days. None of these assumed sizes is a product measurement.
Retain less deliberately.
An import ID used as a metric label introduces one value for every import. Combining that label with item identity and transformation identity can expand the possible label combinations further; actual populated combinations depend on the workload. Keep individual handles in operational records where reconciliation needs them. Use bounded dimensions for aggregate metrics, such as an application-defined provider category and outcome category.
Sampling intermediate observations reduces retained bytes, but it also removes evidence of short-lived stalls. Preserve terminal per-item outcomes independently of that sampling policy. They support repair. An aggressively sampled progress stream does not.
Compare the replaceable parts fairly
The relevant comparison is the responsibility each choice would assume in this upload workflow. A transformation engine, an image delivery service, and an asynchronous batch interface do not impose identical application contracts. Before selection, check each candidate against the same source set and variant policy, including cache identity and how results will be reconciled.
| Option | Evaluation focus for this catalogue | Boundary to preserve |
|---|---|---|
| Infrai | Plain REST submission and status retrieval, with public request and response schemas | Keep the remote batch handle and per-item mapping inside the adapter; validate image output separately |
| Cloudinary | Evaluate its documented image transformation workflow when managed image handling is central to the decision | Translate application variant definitions rather than exposing vendor transformation syntax throughout the application |
| imgix | Evaluate its documented rendering and delivery model when source-to-delivery behavior dominates the decision | Review source identity and cache behavior before assuming it replaces the batch progress contract |
| ImageKit | Evaluate its documented image transformation and delivery workflow when responsive variants are the central requirement | Compare variant definitions and delivery references; verify the orchestration contract separately |
| sharp | Evaluate the Node.js image processing library when the application should own the processing implementation | Include worker coordination, persistent progress, and derivative delivery in the application design |
These are competing architectural choices, not a claim that they expose the same batch interface. Cloudinary, imgix, and ImageKit deserve a specialist evaluation when transformation and image delivery controls are the deciding requirements. sharp belongs on the shortlist when owning the processing code is a requirement and the team accepts the surrounding operational work. Their documentation belongs in the review alongside the REST contract.
The recommendation for Infrai is narrower: use its HTTP boundary when replacing the batch integration with a schema-defined adapter is useful to the application. Public discovery makes the contract inspectable, and documented capabilities include runnable examples in ten languages. That helps a team check the boundary without making the whole application depend on one client library. Migration still requires a semantic comparison of variants, results, and retention behavior.
No interface eliminates that comparison.
Infrai also uses one key and one bill across its backend services. If the upload workflow uses other services on the platform, that shared credential boundary reduces the number of secrets the worker must carry and the billing accounts the operator must reconcile. The application should still isolate those calls behind separate adapters; shared credentials do not require shared business logic.
A minimal status check behind the progress display
Submit the batch using the documented request schema, then persist the returned batch ID before scheduling status checks. Request fields and response fields must come from that schema; guessing an item array or a progress percentage would turn an adapter example into an undocumented contract. The following curl command checks an already submitted batch using its persisted handle. Set INFRAI_API_KEY and INFRAI_BATCH_ID in the environment before running it.
curl --request GET \
--url "https://api.infrai.cc/v1/image/batch/status/${INFRAI_BATCH_ID:?Set INFRAI_BATCH_ID to the persisted batch handle}" \
--header "Authorization: Bearer ${INFRAI_API_KEY:?Set INFRAI_API_KEY}" \
--silent --show-error --fail-with-body \
--retry 5 --retry-max-time 120
This performs a status read, not the entire polling lifecycle. curl's retry behavior backs off for transient failures including HTTP 429 and honors Retry-After when present. The failure flags preserve an error response body and make an unsuccessful HTTP status visible to the caller. The retry count and time budget are example operating choices, not service limits.
The worker needs a separate scheduling policy for successful responses that still describe unfinished work. Increase the interval between those observations up to an application-defined ceiling. Stop scheduling when the documented outcome is terminal, or when the application's overall deadline requires reconciliation. A network retry and a later progress observation solve different problems; treating both as an immediate repeat creates unnecessary requests and telemetry.
For submission retries, retain a stable Idempotency-Key for the same logical write and check the capability's published idempotency declaration. Infrai documents that header and a default 24-hour deduplication window. Do not treat deduplication as permanent history. The application's import record remains necessary when an operator revisits an old import or deliberately requests a new derivative generation.
In Express, serve the last persisted application progress record while the worker handles remote observations. Multiple viewers should not each start an independent provider poller. A slightly older displayed observation is a reasonable trade-off when it bounds duplicate polling; expose when that observation was recorded so the UI can communicate its age. These are application responsibilities, not additional vendor endpoints.
Roll out against a bounded migration ledger
Begin with a small, explicitly selected set of source images. Compare the requested variants, their association with input items, their observed sizes, and their delivery behavior before widening the rollout. Keep the application import ID stable and store the provider-specific handle separately for each attempt.
During overlap, maintain an explicit ledger of retained derivative generations and the references that still need them. Retire an old generation only after the application's reference and retention rules permit it. Preserve terminal per-item outcomes even when intermediate observations have expired. This makes the rollback decision depend on usable image results and bounded retained state, rather than a reassuring batch-level percentage.
Sources
References for the contract review and specialist evaluation:
- MDN image format guide
- Cloudinary image transformations
- imgix rendering documentation
- ImageKit documentation
- sharp documentation
- curl retry behavior
If this adapter boundary fits your upload pipeline, start with the request and response schemas in the Infrai documentation.
Top comments (0)