How Apps/Websites Talk

Ever clicked a button in an app/website and wondered:

“What actually happens behind the scenes?”

You tap “Login”, and magically you’re inside your account. You refresh a feed, and new data appears.It feels instant. But under the hood, something very structured is happening.

Let’s break it down from scratch.

The most basic idea:

At its core, every app interaction is just this:

• Someone asks for something
• Someone responds with something

That’s it.

In technical terms:

• The client (your app/browser) asks
• The server (backend) responds

But here’s the catch:

How do they understand each other?

They need a common language.

HTTP — the rulebook

HTTP is not fancy. It’s just a set of rules.

It defines:

• How to ask
• How to respond
• What format to use

Think of it like ordering food:

• You (client) place an order
• Waiter (HTTP) carries it
• Kitchen (server) prepares
• Food comes back (response)

The foundation of the web: Client meets Server

A typical flow:

• You open a website
• Your browser sends a request
• Server sends back a response

That’s HTTP in action.

What does a request look like?

A request has 3 simple parts:

• URL → where to go
• Method → what to do
• Data → optional info

Example:

• GET → “give me data”
• POST → “create something”
• PUT → “update something”
• DELETE → “remove something”

So far, everything is clean.

{
  "request": {
    "url": "https://api.example.com/users",
    "method": "POST",
    "headers": {
      "Content-Type": "application/json",
      "Authorization": "Bearer abc123token"
    },
    "body": {
      "name": "John Doe",
      "role": "Developer"
    }
  }
}

The real problem

Now comes the interesting part. HTTP tells us how to communicate. But it doesn’t tell us:

“How should we design what we send?”

If 10 developers build APIs differently:

• Everything becomes messy
• Hard to understand
• Hard to scale

Without rules, 10 developers will write 10 different APIs:

• Dev 1: /getUserData?id=5 (GET)
• Dev 2: /create_user_now (POST)
• Dev 3: /deleteUser5 (POST)

So people started creating Architectural patterns.

REST — the first widely adopted approach

REST became the default way to design APIs.

The idea is simple:

Everything is a “resource”

Examples:

• /users
• /orders
• /products

And we use HTTP methods on them:

• GET /users → get users
• POST /users → create user
• GET /users/1 → get specific user

It’s predictable. Clean. Easy to learn.

That’s why almost every beginner starts with REST.

Where REST starts to hurt

REST works great… until it doesn’t. Two major issues:

1. Over-fetching

You ask for small data, but get too much.

Example:

• You only need name
• Server sends name + email + address + everything

Wasteful.

The Request You call the standard REST endpoint asking for user number 1. Endpoint (API): GET [https://api.example.com/users/1](https://api.example.com/users/1)

The Response Because REST is tied to the “Resource” (the User), the server blindly grabs the entire user file from the database and throws it at you.

{
  "id": 1,
  "name": "Alex",        // <-- This is the ONLY thing you actually wanted!

  "email": "alex@example.com", 
  "phone": "+1-555-0198",
  "date_of_birth": "1990-05-14",
  "address": {
    "street": "123 Main St",
    "city": "Springfield",
    "zip": "62701"
  },
  "purchase_history": [
    {"item": "Laptop", "price": 999},
    {"item": "Mouse", "price": 25}
  ],
  "account_status": "active",
  "last_login": "2026-03-28T08:30:00Z",
  "theme_preference": "dark_mode"

  // ... WHO ASKED FOR ALL THESE?!
}

Why this is wasteful:

• Wasted Bandwith — downloading 50 lines of text when only needed 1
• Wasted Memory — client has to process & hold all this useless junk

2. Under-fetching

You don’t get enough.

So you make:

• 1 request for user
• 1 request for posts
• 1 request for comments

Now your app is making multiple calls.

Slow + inefficient.

Request 1: Get the User First, you have to ask for the user’s basic info. Endpoint (API): GET [https://api.example.com/users/1](https://api.example.com/users/1)

{
  "id": 1,
  "name": "Alex",
  "post_ids": [101, 102] 

  // WAIT, where are the actual posts?! I only got the ID numbers! 
  // Now I don't have enough data to show the screen.
}

Request 2: Get the Posts Because you only got ID numbers, your app now has to make a second trip across the internet to fetch the actual content of those posts.

Endpoint (API): GET [https://api.example.com/users/1/posts](https://api.example.com/users/1/posts)

[
  {
    "post_id": 101,
    "content": "Learning about APIs!",
    "comment_ids": [55, 56] // Oh no, not again...
  },
  {
    "post_id": 102,
    "content": "REST is getting annoying.",
    "comment_ids": [57]
  }
]

Request 3, 4, and 5: Get the Comments Now your app has the posts, but it only has the ID numbers for the comments. So, it has to fire off even more requests to finish loading the page.

GraphQL — more control for the client

GraphQL was introduced to solve this.

The idea flips:

Instead of server deciding what to send, the client decides what it needs.

You literally ask:

• “Give me name and email only”

And that’s exactly what you get.

No extra data. No missing data.

The Request: Remember the nightmare of needing the User, their Posts, and the Comments, which took 5 different requests in REST?

With GraphQL, you just nest your shopping list. You make ONE request.

{
  "request": {
    "url": "https://api.example.com/graphql",
    "method": "POST",
    "body": {
      "query": "{ user(id: 1) { name, posts { content, comments { text } } } }"
    }
  }
}

(Translation: “Get user 1’s name. Then get their posts’ content. Then get the text of the comments on those posts.”)

The Response: The server does all the heavy lifting in the background, gathers everything together, and sends it back in one perfect package.

{
  "data": {
    "user": {
      "name": "Alex",
      "posts": [
        {
          "content": "Learning about APIs!",
          "comments": [
            { "text": "Great post!" },
            { "text": "Keep it up." }
          ]
        },
        {
          "content": "REST is getting annoying.",
          "comments": [
            { "text": "I agree, REST can be slow." }
          ]
        }
      ]
    }
  }
}

Why this feels powerful

• Fewer requests
• Exact data
• Better for frontend apps

Think of it like:

Ordering exactly what you want, nothing more, nothing less.

gRPC — speed over flexibility

Now comes a different approach. While REST and GraphQL focus on flexibility, gRPC focuses on:

Performance and efficiency

Key ideas:

• Uses binary (not text) → faster
• Strong contracts → strict structure
• Great for backend communication

When does this matter? In systems like:

• Microservices
• High-performance backend systems

Where speed matters more than readability.

Simple way to think about it:

• REST → human-friendly
• GraphQL → flexible
• gRPC → machine-efficient

So… which one should you use?

There’s no “best”. Only trade-offs.

• Use REST → when things are simple
• Use GraphQL → when frontend needs control
• Use gRPC → when performance is critical

Final thought

Most beginners try to find the “best” technology. But in reality:

Good engineers don’t chase tools — they understand problems.

HTTP is the foundation. REST, GraphQL, and gRPC are just different ways to build on top of it.