A civic inventory table with thousands of rows issues one REST call per row to a Cisco platform API, and the page feels slow even though each call is fast. What latency design change should be preferred?
Select an answer to reveal the explanation.
Short Explanation
Asking for each library book one whisper at a time loses even if every whisper is quick. Prefer a bulk or filtered list the platform already offers. Chunky beats chatty for multi-thousand-row tables.
Full Explanation
A civic inventory table with thousands of rows that issues one REST call per row is chatty: even fast individual calls sum to large latency, connection overhead, and quota burn. Prefer list, bulk, or server-side filtered endpoints the Cisco platform already offers, or a back-end aggregation that pages efficiently, so one or a few hops return the needed set.
Keeping per-row calls and only opening more parallel browser connections fails because chatty shape remains; parallelism can even trip rate limits faster. Replacing the table with manual CSV export fails the interactive portal goal and pushes operational burden onto staff. Adding sleep between per-row calls fails by deliberately slowing an already poor conversation shape.
Exam caveat: if only item GETs exist, batch on the server with concurrency limits and caching—still avoid browser-side per-row storms.
Operational check: compare page load time and platform call count for per-row versus list or bulk access on a multi-thousand-row dataset; call count should drop by orders of magnitude.
Chatty per-row conversations also complicate tracing and retries: thousands of tiny failures are harder to reason about than one paginated list call with clear total counts. Prefer platform search or bulk inventory APIs, then render locally. If the platform forces item GETs, aggregate server-side with a worker pool and cache—not from each clerk browser.