Every App You Use Is Really Just a Conversation

You interact with dozens of apps every day. Each one is having a conversation you can't hear.

Your phone asks a server for your feed. The server checks a database, assembles a response, and sends it back. Your phone renders it. All of that happens in a fraction of a second, and you never think about it — the same way you don't think about the electrical grid every time you flip a light switch.

Once you understand the shape of that conversation, a huge amount of modern technology stops feeling mysterious.

That's what clicked for me recently. Not the specific tools or languages, but the patterns. The same handful of patterns show up everywhere — in web apps, in mobile apps, in smart devices, in voice assistants. And what made them finally stick was realizing they also show up in restaurants, kitchens, apartment buildings, and coffee shops.

A restaurant is a client-server system

When you walk into a restaurant, you sit down. You look at the menu. You tell the waiter what you want. The waiter walks to the kitchen, relays your order, the kitchen prepares it, and the waiter brings it back.

That's client-server.

You're the client. The kitchen is the server. The waiter is the network. The menu is the interface.

Every app on your phone follows this exact pattern. You tap something (request). Something processes it (server logic). Data comes back (response). Netflix, Uber, your banking app — all of them.

The web didn't invent this pattern. Restaurants, libraries, post offices — they've been doing request/response for centuries. Modern software just made it run at the speed of light.

And here's the part that reframed things for me: the server can respond with two very different things. It can hand you a finished dish — a complete web page with all the visual elements baked in. Or it can hand you raw ingredients — just the data, and let the client decide how to present it.

That second option — raw data — is what made mobile apps, smart devices, and voice assistants possible. Alexa doesn't need a web page. It needs data it can speak. Your watch doesn't need HTML. It needs numbers it can display on a tiny screen.

Same kitchen. Different plates.

Four verbs run almost everything

In a restaurant, you really only do a handful of things with an order. You place a new one, ask what's available, change something, or cancel.

The protocol that powers the web works the same way. It has four main actions:

Think about real estate:

• GET: browsing listings on Zillow — you're asking for information that already exists
• POST: submitting an offer on a house — you're creating a new record that didn't exist before
• PUT: updating your offer price because someone outbid you — you're modifying something
• DELETE: withdrawing your offer entirely — you're removing it

Or think about your phone contacts. You look someone up (GET). You add a new contact (POST). You update their phone number when they switch carriers (PUT). End of semester, you delete that group project partner you'll never speak to again (DELETE).

A staggering amount of modern software is just these four operations applied to different kinds of data. It's like learning that every sentence has a subject and a verb — once you see the structure, the complexity becomes manageable.

Routing is the building's reception desk

Imagine walking into a large office building. You tell the receptionist: "I'm here for Dr. Kim in cardiology, 4th floor."

The receptionist doesn't do your heart checkup. They check a directory and point you to the right place.

That's routing. When a request arrives at a server, something has to look at what's being asked for and decide: which piece of code should handle this?

Think of it like a switch operator at an old telephone exchange. A call comes in, they look at the number, and patch it through to the right line. They don't participate in the conversation. They just connect the caller to the right destination.

And if you ask for something that doesn't exist? You get the equivalent of "sorry, no one here by that name." In web terms, that's a 404 error — the server saying "I looked everywhere, and I don't have what you're asking for."

The 404 error code, by the way, was just a number someone picked decades ago.

• 200 means "everything went fine.".
• 404 means "not found.".
• 500 means "something broke on my end, sorry.".

There's a whole catalog of these response codes, and they work like standardized status updates. The server doesn't have to explain what went wrong in a paragraph. It sends a number, and everyone agrees on what that number means.

Ports are apartment numbers

When you mail a letter, the street address gets you to the building. But the apartment number gets you to the right door.

In networking, IP addresses are the street addresses. Ports are the apartment numbers.

Your computer has thousands of available ports. Different services listen on different ones. When your browser goes to google.com, it's actually talking to port 443 — the standard for secure web traffic. You just never see it because browsers hide it automatically, like how you don't write "Planet Earth" at the bottom of every mailing address.

When developers are building something locally, they'll often see ports like 8000 or 3000. That's their development server's apartment number. And if you try to start two servers on the same port? Same problem as two tenants trying to move into the same apartment. Someone's getting a conflict.

There's also a special address that trips people up at first: 127.0.0.1, also known as localhost. It's the networking equivalent of talking to yourself. Your computer sends a request, and its own networking layer catches it and routes it right back internally. No internet involved.

This is how developers test things before deploying them to the real world. The browser (client) and the server are both running on the same machine, talking to each other through localhost. It feels weird at first — like being both the restaurant and the customer — but it makes perfect sense once you think of "client" and "server" as roles, not physical machines.

JSON is the universal order form

When the kitchen gets your order, it helps if the slip follows a consistent format. Not a rambling paragraph about your relationship with steak, but a structured form: item, quantity, modifications, table number.

JSON (JavaScript Object Notation) is that order form for the digital world. It's a way of structuring data so that both humans and computers can read it.

It's just key-value pairs wrapped in curly braces: {"name": "Anh", "order": "pasta", "extra_cheese": true}

If you've ever seen a Python dictionary, it looks almost identical — because Python borrowed the format intentionally. Almost every modern service speaks JSON. It's the shared language between the kitchen and the dining room, between the server and the client, between your phone and the cloud.

The reason JSON won out over other formats is that it's dead simple. You can look at a JSON object and immediately understand what it means. No special decoder ring needed. That simplicity turned it into a universal standard.

Cooking multiple dishes at once is async programming

Here's where things get genuinely interesting — and where most people's intuition breaks.

If you cook dinner and make everything one step at a time — boil the pasta, wait until it's completely done, then start the sauce, wait again, then chop the salad — dinner takes an hour and a half. That's synchronous execution. One thing at a time, strictly in order.

But no real cook works that way. You start the pasta boiling and while it cooks, you start the sauce. While the sauce simmers, you chop the salad. Multiple things run in parallel, and you check on each one when it's ready.

That's asynchronous programming. You kick off a task, and instead of standing there staring at the pot, you go do other useful work. When the task finishes, you come back to handle the result.

This matters enormously in software because network requests are slow. If your app froze every single time it asked a server for data — if it stood at the stove staring at the pasta — the experience would be unbearable. Instead, the app sends the request and keeps running. When the data comes back, it handles it.

The part that trips everyone up

The tricky bit — and this genuinely catches everyone the first time — is that you can't assume the data is ready just because the next line of code runs.

In synchronous code, line 2 runs after line 1 finishes. Guaranteed.

In async code, line 2 might run before line 1 has returned its result.

That's like assuming the pasta is done just because you've finished chopping the salad. You started the pasta first, sure. But the salad was faster.

If you write code that assumes the fetched data is already in x by the time you print it, you'll get the old value. Not because you made a logic error, but because the kitchen hasn't finished cooking yet and you already set the table.

Once you know this is coming, you can program around it. But if nobody warns you, it feels like the computer is broken. It's not. It's just cooking multiple dishes at once, and you assumed one was done before it actually was.

"We'll call your name when it's ready" — that's a promise

Some coffee shops take your order and hand you a buzzer. "We'll buzz you when it's ready." You don't stand at the counter blocking everyone behind you. You go sit down, check your phone, do whatever. When the buzzer goes off, you pick up your drink.

In programming, that buzzer is called a Promise. And the .then() keyword is you saying: "when it's ready, then do this with it."

The pattern looks like this in practice:

1. Ask for something (place the order)
2. Get a promise back (receive the buzzer)
3. Keep doing other things (sit down, scroll your phone)
4. When the result arrives, then handle it (buzzer goes off, go get your drink)

The beauty of this pattern is that the app never freezes. It places the order, goes about its business, and handles the result whenever it arrives. That's why modern apps feel responsive even when they're talking to servers on the other side of the planet.

And you can chain promises: then do this, then do that. Like: when the coffee is ready, then add sugar, then take a sip. Each step waits for the previous one, but the rest of the world keeps moving while you wait.

Threads are kitchen staff

When a restaurant gets busy, one cook can't handle everything. So you add more cooks. Each cook works on their own dish, sharing the same kitchen, the same ingredients, the same equipment.

That's the difference between processes and threads in computing.

A process is like an entire restaurant — it has its own space, its own staff, its own everything. It's heavy to start and expensive to run. When you double-click an app on your computer, you're starting a new process.

A thread is like a single cook within that restaurant — lightweight, shares resources with the other cooks, and can be spun up quickly when things get busy.

Your browser, your web server, your database — all of them use multiple threads to handle many requests simultaneously. That's why you can have 20 tabs open and they all load at the same time. Each tab gets its own thread (roughly), sharing the browser's overall process.

The flip side of shared resources is shared problems. If two cooks reach for the same knife at the same time, you've got a conflict. In programming, this is called a race condition — two threads trying to read or modify the same piece of data simultaneously. Managing this is one of the genuinely hard parts of concurrent programming. But the concept? Two cooks, one knife. You already get it.

Everything is event-driven — even waiting tables

Here's one more restaurant insight that maps perfectly to software.

A good waiter doesn't constantly walk to each table asking "are you ready to order yet?" That would be annoying and inefficient. Instead, they watch for signals. A customer puts down their menu — that's an event. The waiter responds.

That's event-driven programming. Instead of constantly checking "did something happen yet?", the system sits idle and reacts when something does happen. A click, a keystroke, a network response arriving, a timer going off — all events.

Your operating system works this way. It's not frantically checking every millisecond whether you've moved your mouse. It waits. When you move the mouse, that generates an event, and the OS responds. Efficient, responsive, and scalable.

Combine async programming with event-driven design, and you get systems that can handle thousands of concurrent users without breaking a sweat. The kitchen doesn't cook one order at a time, and the waiter doesn't stand at one table until they leave. Everything flows.

Why this connects to building products people want

All of this might feel purely technical. But here's why it keeps pulling me back to product thinking.

If you're building something for real users, these patterns directly shape the experience:

• Response time is the waiter's speed. A slow server feels like a slow restaurant — people leave. Studies show that even a 100-millisecond delay in response time can reduce conversion rates.
• Good routing is a well-organized menu. A clean API is easy to navigate and hard to misuse. A messy one creates confusion and bugs.
• Async design determines whether your app feels alive or frozen. Nobody wants to stare at a spinner while the rest of the screen is locked.
• Threads and concurrency determine how many customers your restaurant can serve at once. Scale isn't just about having a bigger kitchen — it's about how efficiently your cooks work together.

The engineers who understand both the value proposition and the technical architecture — who think about the customer's experience while designing the system — are the ones who build things that actually work well. Not just technically correct, but genuinely good to use.

Understanding how the kitchen works doesn't make you a chef. But it makes you a much better restaurant owner.

A few things I'm taking away

• Client-server is not a web-only concept — it's a communication pattern that shows up in restaurants, libraries, and post offices, anywhere someone asks for something and someone else provides it
• Almost everything digital boils down to four operations: read, create, update, delete — the same actions you'd take with a phone contact or a real estate listing
• Routing is just a reception desk — match the incoming request to the right handler, and let the handler do the actual work
• Ports are apartment numbers on your computer — different services live at different ports, and two services can't share one
• Async programming is cooking multiple dishes at once — the hard part isn't the concept, it's remembering that you can't assume the pasta is done just because you finished the salad
• Promises are coffee shop buzzers — "go do your thing, we'll notify you when it's ready"
• Threads let your system handle many things simultaneously, like multiple cooks sharing one kitchen — powerful, but the shared resources create real coordination challenges
• Event-driven systems don't poll constantly — they wait for signals, like a good waiter who watches for cues instead of interrupting every 30 seconds
• During development, your computer plays both client and server on the same machine, which is confusing at first but makes perfect sense once you see these as roles, not locations
• The engineers who connect product thinking to system design are the ones who build things people actually want to use — not just technically sound, but genuinely good

That last one is where it all lands. You can understand every protocol, every pattern, every architectural concept in isolation. But the real skill is connecting the kitchen to the dining room — understanding how the system you're building translates into the experience someone actually has. And honestly, that feels like the kind of thinking that compounds over time, long after any specific tool or framework has been replaced.

Sources

• HTTP Status Codes (MDN Web Docs) — the full catalog of status codes and what they mean
• JSON specification (json.org) — the original spec for JavaScript Object Notation
• Asynchronous Programming (MDN Web Docs) — comprehensive guide to async concepts and promises
• Concurrency vs Parallelism (Rob Pike) — classic talk distinguishing between the two concepts