Building the Cart Page

Suppose the shop has two clients: a website, for a desktop browser, and a phone app, for a phone.

The website has a large screen, so it can show more information at once. The phone app has a small screen, so it needs to be more selective about what it shows. For example, when we list the products in a cart, the website might include a product’s description, while the phone app might drop the description, because it is too long to fit on the small screen.

From the phone app’s perspective, it is over-fetching because it receives fields it does not use. In fact, each product also stores other information, such as the stock quantity, that neither client uses. So the website is also over-fetching. But over-fetching is more of a problem for the phone app. Most of the bytes in the responses are the product descriptions, so more of what the phone app downloads is waste. The phone app also typically has a slower network connection and less memory than a desktop browser.

There is a second problem. The cart response carries only the product identifiers and their quantities. The client has to make an additional request for each product to get the fields it needs to display the cart page. The website needs a product’s description, so it has to make those additional requests. This is under-fetching, the opposite of over-fetching.

You can send the product requests at the same time, but you still have to wait for the cart response before you can send the product requests. So at least two rounds of requests are needed to build the cart page. This extra round trip is more of a problem for the phone app than for the website, because a round trip costs more time on a slower connection.