Lesson 1.1 - REST vs GraphQL

#reactnativemastery #reactnative

Lesson 1.1 - REST vs GraphQL

Good morning, class! Welcome to the very first lesson of our course.

Before we jump ahead to writing Apollo Client code, before we discuss caching mechanisms, and before we start layout development on our mobile product screens, we need to anchor ourselves in a fundamental architectural concept: the core operational differences between REST and GraphQL.

Our Goal today is highly focused: we are going to look at both API communication styles strictly from the perspective of a React Native developer building real-world, data-driven mobile screens.

1. The API Problem Every Mobile App Has

Let’s be honest: every mobile application is essentially a visual wrapper around data.

A product list screen needs product records. A category filter drawer needs taxonomy trees. A checkout screen needs historical order logs. The architectural hurdle is never about whether your frontend application needs to communicate with a backend database. The real problem we face daily is:

How does a specific screen efficiently request the exact data it needs to render its layout?

REST and GraphQL approach this exact question from completely opposite engineering mindsets.

2. What REST Looks Like

REST (Representational State Transfer) is an API design style where the backend exposes data through multiple individual URLs, which we refer to as Endpoints.

Take a look at these real examples from our e-commerce backend architecture:

GET https://backend.ecom.subraatakumar.com/api/v1/products?page=1&size=10
GET https://backend.ecom.subraatakumar.com/api/v1/categories

In a traditional REST architecture, the endpoint dictates the shape of the data payload.

If the backend team configured the /products endpoint to return 45 data fields per item block, your React Native app will pull all 45 fields over the cellular network—even if your mobile layout only renders 3 of them (like name, price, and imageUrl).

This doesn't make REST inherently bad. REST is deeply familiar, straightforward, predictable, and runs a massive portion of the modern web. However, as mobile application layouts become highly tailored and dynamic, REST can occasionally back the client application into a corner, forcing it to swallow rigid data footprints designed for desktop environments.

3. What GraphQL Looks Like

GraphQL is a strongly-typed query language and runtime for APIs.

Instead of forcing your mobile UI to hit a dozen disconnected endpoints to build a single view, a GraphQL app sends a declarative query to a Single, Unified Endpoint and explicitly dictates the exact fields it requires to render its current layout view.

Our e-commerce GraphQL gateway address is:

POST https://backend.ecom.subraatakumar.com/graphql

Here is a look at a basic query document:

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

If you read this code block like a plain English sentence, it says:
"Dear backend server, for this specific mobile product list screen, fetch page 1 containing 10 items, but only return the id, name, price, and imageUrl fields for those items. Leave everything else behind."

This is the first critical mental paradigm shift you must master.

4. The Main Architectural Difference

To put it in simplest terms:

REST is Endpoint-First.
GraphQL is Screen-Data-First.

Let's break down the developer thought process side-by-side:

Architectural Approach	Core Question Asked by Frontend Dev
REST Mindset	"Which specific endpoint or collection of URLs gives me access to this resource?"
GraphQL Mindset	"What are the precise data properties this specific screen component needs to render right now?"

For React Native engineers, this distinction is crucial. Mobile apps operate on smaller displays, run on resource-constrained hardware, and face erratic cellular network performance. Eliminating bloated payloads directly improves app responsiveness.

5. REST Request Example

Let’s look at a standard JavaScript implementation fetching data from our REST endpoint:

async function fetchProductsWithRest() {
  const response = await fetch(
    "https://backend.ecom.subraatakumar.com/api/v1/products?page=1&size=10"
  );

  if (!response.ok) {
    throw new Error("Failed to load products");
  }

  return response.json();
}

Notice the key mechanical takeaway here: The URL structure completely controls what data payload drops into your application state.

6. GraphQL Request Example

Now, let’s observe how we accomplish the exact same product fetching intent using GraphQL via low-level native fetch:

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

  const result = await response.json();

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

  return result.data.products.data;
}

Notice the functional shift here: The HTTP endpoint stays completely static, but the inner query payload directly controls the shape and size of the incoming response.

7. What React Native Developers Should Remember

A common beginner pitfall is framing this engineering choice as an absolute binary battle: "REST vs GraphQL—which tool wins?" That is entirely the wrong lens to view your system architecture through.

The useful question you should be asking yourself as a mobile product engineer is this:

"Can my current screen component request only the exact properties it requires to render its layout, within the fewest possible round-trips over the network?"

GraphQL was engineered specifically from the ground up to solve that exact optimization problem for client apps.

Check Your Understanding

Before packed up and heading out to our next hands-on coding lab, make sure you can confidently answer these three architectural review questions:

In a traditional REST API ecosystem, who fundamentally controls the structural shape of the data response?
In a GraphQL ecosystem, who assumes control over choosing which data fields are returned for a mobile screen layout?
Why does minimizing raw payload size and network round-trips matter significantly more for mobile hardware form factors than desktop web browsers?