Good morning, everyone! Welcome back. In our previous lesson, we compared REST and GraphQL at a high, architectural level.

Today, we are going one layer deeper. Our Goal today is to analyze the first two critical API data-fetching problems that show up repeatedly in production-grade React Native applications: over-fetching and under-fetching.

Understanding these two issues will show you exactly why so many engineering teams choose to migrate their mobile applications to GraphQL.

1. Problem One: Over-Fetching

Over-fetching simply means that the backend API sends significantly more data fields over the wire than your specific screen layout actually requires to render.

Let's look at a concrete mobile use case. Imagine you are building a product preview card for a grid view. The UI layout only displays three pieces of information:

• Product image
• Product name
• Price

However, when you fire a request to your standard REST endpoint, the server hands you back this entire payload block:

{
  "id": 1,
  "name": "Apple",
  "price": 40,
  "category": "Fruits",
  "imageUrl": "https://example.com/apple.png",
  "description": "Fresh red apples",
  "brand": "Farm Fresh",
  "inStock": true,
  "quantity": 25,
  "unit": "kg",
  "discount": 5,
  "rating": 4.7
}

Look at that JSON object. While properties like description, quantity, unit, and brand are absolutely vital when a user clicks through to a dedicated Product Details screen, they are completely useless waste on a high-level catalog screen.

When developing for mobile devices, this extra payload volume is not harmless metadata. Your users are interacting with your app on the move—often navigating fluctuating cellular networks, capped data plans, hardware with limited memory overhead, and battery-sensitive operating conditions. Wasting bytes on fields that are immediately discarded strains those mobile resources.

2. GraphQL Fix One: Ask for Only the Needed Fields

GraphQL eliminates this waste by putting selection power back in the hands of the client interface.

When rendering our simple product preview cards, we can construct a selection set containing exclusively the fields our layout binds to:

query ProductCards {
  products(page: 1, size: 10) {
    data {
      id
      name
      price
      imageUrl
    }
  }
}

Now, let’s look at how the exact same schema resource behaves when we shift context over to the comprehensive Product Details screen:

query ProductDetails {
  products(page: 1, size: 10) {
    data {
      id
      name
      price
      imageUrl
      description
      brand
      rating
      discount
      inStock
    }
  }
}

Notice the power here: We are hitting the exact same data resource gateway, but with completely different selection sets tailored perfectly to distinct UI requirements. That is our first major GraphQL architectural fix.

3. Problem Two: Under-Fetching

Conversely, Under-fetching means that a single endpoint fails to provide enough comprehensive data to satisfy what a single screen layout needs to render.

Consider a modern, highly dynamic e-commerce marketplace Home Screen. To provide a rich landing experience, this view simultaneously requires:

• A featured list of trending products
• A horizontal scrolling list of category chips
• The logged-in user's active shopping cart context or recent order history

In a traditional REST architecture, this structural layout regularly forces you to coordinate and chain together multiple independent network requests:

GET /api/v1/products?page=1&size=10
GET /api/v1/categories
GET /api/v1/orders

As a mobile developer, this shifts a heavy orchestration burden onto your React Native codebase. Your UI layer suddenly has to elegantly coordinate three separate asynchronous network cycles, manage multiple individual loading spinners, catch unique localized error states, and configure fallback retry paths if request two fails while requests one and three succeed.

This state complexity isn't a theoretical edge case—it is a production reality that compounds quickly as mobile layout requirements grow.

4. GraphQL Fix Two: Request Related Data Together

GraphQL cleanly resolves under-fetching by allowing client components to request multiple, completely distinct root resource fields inside a single, unified network transaction block.

Here is how we can aggregate our homepage data requirements into a clean operational query payload:

query HomeScreenData {
  categories
  products(page: 1, size: 10) {
    meta {
      total
      page
      pages
    }
    data {
      id
      name
      price
      imageUrl
      category
    }
  }
}

💡 A quick note on architecture: This does not mean you should bundle every single piece of data across your entire application into one gargantuan query document. It simply means that GraphQL hands you a flexible API layer capable of cleanly packaging related data blocks into a single round-trip whenever it makes your UI rendering architecture simpler and cleaner.

5. React Native Implementation Example

Let’s look at how this unified homepage fetching logic translates into a low-level JavaScript function within a mobile environment using standard fetch:

async function loadHomeScreenData() {
  const response = await fetch("https://backend.ecom.subraatakumar.com/graphql", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      query: `
        query HomeScreenData {
          categories
          products(page: 1, size: 10) {
            data {
              id
              name
              price
              imageUrl
              category
            }
          }
        }
      `,
    }),
  });

  const json = await response.json();

  if (json.errors) {
    throw new Error(json.errors[0].message);
  }

  return json.data;
}

Just like in our previous exercises, we are intentionally executing this request through raw HTTP fetch syntax so you can clearly trace the structural shape of the network request body. We will abstract this boilerplate code away with Apollo Client once we enter Module 3.

6. Core Takeaways

The fundamental advantage of introducing GraphQL into your mobile stack isn't based on magic. It boils down to two straightforward client-side performance principles:

• The mobile client can request less when rendering lightweight, targeted UI elements (Fixing Over-fetching).
• The mobile client can request more data fields aggregated together when populating complex, multi-source layouts (Fixing Under-fetching).

This dual-axis optimization immediately simplifies state management routines and lowers data overhead on mobile devices.

Check Your Understanding

Take a brief moment to review these questions silently to ensure today's architectural concepts are locked in:

1. In your own words, what is the core operational cost of over-fetching in a cellular mobile application environment?
2. How does under-fetching directly complicate state and error management inside your React Native UI components?
3. What mechanism does GraphQL use to grant the mobile client complete control over the structural shape of the incoming response payload?

External Reading

To expand on these core design topics before we start our upcoming practical coding session, explore these official reference guides:

• GraphQL Core Concepts: Over-fetching vs Under-fetching Analysis
• MDN Web Docs: Optimizing Mobile Performance Over Cellular Networks

Excellent concentration today, everyone. Pack up your laptops, and I will see you all in our next session!

Thanks for reading.

Connect with me:

• GitHub: https://github.com/TechCraft-By-Subrata
• LinkedIn: https://www.linkedin.com/in/subraatakumar/
• YouTube: https://www.youtube.com/@techcraftclub
• Instagram: https://www.instagram.com/subraatakumar/
• Reddit: https://www.reddit.com/r/ReactNativeMastery/
• DEV.to: https://dev.to/subraatakumar
• Discord: https://discord.gg/cA5fhVT8
• WhatsApp: https://whatsapp.com/channel/0029VbCz72vFCCoUsMV4K30M
• Topmate: https://topmate.io/subrata
• React Native Mastery: https://rnm.subraatakumar.com/