A code app screen shows 200 orders. For each order, it loops over the rows and calls CustomersService.get with the order's customer ID to display the customer name, issuing 200 extra requests. What pattern should replace the loop?
Select an answer to reveal the explanation.
Short Explanation
This is the classic chatty-app trap: one trip to the store for every item on your list. Collect the distinct customer IDs and fetch them in a single set-based query. Running the 200 trips in parallel just gets you to the same traffic jam faster.
Full Explanation
Per-row lookups create an N plus one request pattern: one query for the list and one more per row. The scalable fix is set-based retrieval. Collecting the distinct customer IDs from the orders and calling getAll once with an OData filter that matches those IDs, plus select on the name and ID columns, returns all needed customers in a single round trip; the app then maps names to orders in memory. Where the data model allows, retrieving orders with related customer data in the original query avoids even the second request. Running the 200 get calls concurrently with Promise.all shortens elapsed time on a fast network but keeps the request count, burdens the service and increases the risk of service protection throttling with many users. Adding select to each call reduces payload size but does nothing about the 200 round trips. A cloud flow called once per order moves the loop to the server but multiplies cost further, adding a flow run plus the lookup for every row. Exam caveat: very long ID lists can exceed URL length limits, so large sets are retrieved in batches of IDs rather than one call per row. Operational check: compare request counts in the network trace before and after, expecting two requests instead of 201.