There is a particular kind of frustration that comes with web development.

You build an API request in Postman. It works perfectly. You get a 200 OK, the response contains exactly the data you expected, and for a brief moment, you feel like everything is finally under control.

Then you open your frontend, click the button that should fetch the same data, and… nothing.

Maybe the browser console shows a CORS error. Maybe the request returns 401 Unauthorized. Maybe the response is perfectly valid, but your UI still displays an empty list. And sometimes, the request doesn't even reach your backend.

My first instinct in situations like this is usually to check the backend again. After all, if the API works in Postman, surely the frontend must be doing something strange.

Well, sometimes it is. But the interesting part is that an API working in Postman doesn’t guarantee that the same request will work in a browser.

Postman and browsers operate under different rules. They don’t necessarily send identical requests, they handle authentication differently depending on configuration, and browsers enforce security restrictions that Postman generally doesn’t enforce in the same way.

Once you understand those differences, debugging API requests becomes much less like guessing and much more like solving a problem systematically.

Let’s walk through the issues I would investigate first.

1. Start by Comparing the Actual Requests

Imagine Kapi is building a small dashboard that fetches a list of users from an API.

The request works in Postman:

GET https://api.example.com/users

The server returns:

{
  "users": [
    {
      "id": 1,
      "name": "Kapi"
    },
    {
      "id": 2,
      "name": "Alex"
    }
  ]
}

Everything looks good. So Kapi writes the following JavaScript:

async function getUsers() {
  const response = await fetch(
    "https://api.example.com/users"
  );
const data = await response.json();
  console.log(data);
}
getUsers();

But when she runs the frontend, the request fails.

Before rewriting the function or changing anything on the backend, I would open the browser’s Developer Tools and inspect the request.

In Chrome, you can usually open Developer Tools with F12 or Ctrl + Shift + J on Windows and Linux, or Cmd + Option + J on macOS. Select the Network tab, reload the page, and click the failed request. The exact shortcuts can vary by browser and operating system.

Look at the request URL, HTTP method, status code, request headers, response headers, and response body. Also check the Console tab for browser security errors.

This gives you something much more useful than a vague message saying the API doesn’t work: evidence of what the browser actually attempted to do.

I like to compare that request with the successful Postman request. Are the URLs identical? Is the same HTTP method being used? Are the headers present? Is the same token being sent? Is the browser following the same authentication flow?

These questions help narrow the problem before you touch a single line of code.

2. The CORS Error That Makes You Question Everything

Let’s start with one of the most common problems in frontend development: CORS.

CORS stands for Cross-Origin Resource Sharing. It’s a browser security mechanism that controls whether JavaScript running on one origin is allowed to access a response from another origin.

An origin consists of the scheme, host, and port. For example, these are different origins:

• http://localhost:3000
• http://localhost:5000
• https://api.example.com

Even though the first two use localhost, their ports differ, so they are considered separate origins.

Suppose your React application runs at:

http://localhost:3000

And your backend runs at:

http://localhost:5000

Your frontend sends a request:

fetch("http://localhost:5000/users");

The browser checks whether the backend’s response permits the frontend’s origin. If the required CORS headers are missing or don’t match, the browser prevents frontend JavaScript from accessing the response.

This is where things get confusing.

The backend might successfully receive the request and generate a perfectly valid response. Yet the browser still refuses to expose that response to your application.

Postman, on the other hand, doesn’t enforce browser CORS rules in the same way. That’s why the same endpoint can work in Postman and fail in your frontend.

How do you fix it?

Usually, you need to configure CORS on the server or through the server’s gateway or reverse proxy.

For example, an Express application using the cors package might look like this:

import express from "express";
import cors from "cors";
const app = express();
app.use(cors({
  origin: "http://localhost:3000"
}));
app.get("/users", (req, res) => {
  res.json({
    users: [
      { id: 1, name: "Kapi" },
      { id: 2, name: "Alex" }
    ]
  });
});
app.listen(5000, () => {
  console.log("Server running on port 5000");
});

Here, the server permits browser requests from the specified frontend origin. In a real application, you should configure the allowed origins for your deployment environments rather than blindly copying development settings into production.

Some requests trigger a preflight request, which uses the OPTIONS method. This happens when the browser needs permission to send a cross-origin request with certain methods or headers.

For example, a request containing an Authorization header or a custom header commonly triggers a preflight.

The browser might send something like:

OPTIONS /users HTTP/1.1
Origin: http://localhost:3000
Access-Control-Request-Method: GET
Access-Control-Request-Headers: authorization

The server must respond with appropriate CORS headers allowing the requested origin, method, and headers.

If the preflight fails, the browser may never send the actual request.

One important detail: CORS is not a replacement for authentication or authorization. It controls browser access to cross-origin responses; it does not stop a client such as Postman or a server-side script from calling a publicly reachable endpoint.

Also, don’t try to fix CORS by disabling browser security. Configure the server correctly.

3. Your Frontend Is Missing an Authentication Header

Here’s another situation I’ve run into more than once.

The endpoint works perfectly in Postman, but the browser returns:

401 Unauthorized

At first, it looks like the backend is rejecting a valid request for no reason.

But when you inspect Postman’s request headers, you notice something important:

Authorization: Bearer YOUR_ACCESS_TOKEN

Postman is sending an access token. Your frontend isn’t.

The backend isn’t behaving inconsistently. You’re simply making two different requests.

If an API requires a bearer token, your frontend might need to send it like this:

async function getUsers(accessToken) {
  const response = await fetch(
    "https://api.example.com/users",
    {
      headers: {
        Authorization: `Bearer ${accessToken}`
      }
    }
  );
if (!response.ok) {
    throw new Error(
      `Request failed: ${response.status}`
    );
  }
  return response.json();
}

The token in this example should come from your application’s actual authentication flow. Don’t hardcode a real secret or access token into source code that will be shipped to the browser.

There is another important distinction here: a 401 usually means authentication is missing or invalid, while a 403 generally means the server understood the request but refuses to authorize the operation. Exact conventions depend on the API, but the distinction is useful when debugging.

Also, if your application uses cookie-based authentication rather than bearer tokens, the solution can be different. Cross-origin fetch() requests don't include credentials by default. You may need:

fetch("https://api.example.com/users", {
  credentials: "include"
});

For cross-origin cookie-based requests, the server must also configure credentialed CORS correctly, including a specific allowed origin rather than *, and return Access-Control-Allow-Credentials: true. Cookie attributes and browser privacy policies can affect whether the cookie is sent, too.

The key is to understand which authentication mechanism your backend expects instead of adding random headers until the request starts working.

4. A Successful Response Doesn’t Always Mean Your Code Is Correct

Sometimes the request succeeds, but the frontend still breaks.

This is arguably more annoying because the Network tab shows 200 OK, and you start wondering whether the browser is playing a prank on you.

Consider this example:

async function getUsers() {
  const response = await fetch(
    "https://api.example.com/users"
  );
const data = await response.json();
  console.log(data.name);
}

Suppose the server returns:

{
  "users": [
    { "id": 1, "name": "Kapi" },
    { "id": 2, "name": "Alex" }
  ]
}

The request succeeds. The JSON parses successfully. But data.name is undefined because name isn't a property at the top level of the response.

The names are inside the users array.

The correct code would be:

async function getUsers() {
  const response = await fetch(
    "https://api.example.com/users"
  );
const data = await response.json();
  console.log(data.users);
}

This is a simple example, but response-shape mismatches are common in real applications. Your frontend might expect an array while the backend returns an object containing an array. A property might be named userId rather than id. An API might return null for a field you assumed would always exist.

This is why I prefer inspecting the actual response body before changing the UI code.

Don’t assume that the response matches your mental model just because the status code is successful.

And remember that fetch() generally rejects for network-level failures, not for HTTP error statuses such as 404 or 500. You need to check response.ok if you want those statuses to become application errors.

5. The Request Is Failing, but Your Error Handling Is Hiding the Real Problem

Let’s say your frontend contains this code:

async function getUsers() {
  try {
    const response = await fetch(
      "https://api.example.com/users"
    );
const data = await response.json();
    return data.users;
  } catch (error) {
    console.log("Something went wrong");
  }
}

It looks reasonable at first. There is a try/catch block, so the application won't crash because of an unhandled rejection.

But there’s a problem: the error message tells you almost nothing.

Was the request blocked by CORS? Did the network connection fail? Did the response body contain invalid JSON? Did the code throw somewhere else?

Worse, the function doesn’t return anything from the catch block. If the caller expects an array, it may receive undefined and fail somewhere later, making the original issue harder to find.

During development, I prefer error handling that preserves useful information:

async function getUsers() {
  const response = await fetch(
    "https://api.example.com/users"
  );
if (!response.ok) {
    throw new Error(
      `Failed to fetch users: HTTP ${response.status}`
    );
  }
  const data = await response.json();
  return data.users;
}
getUsers()
  .then((users) => {
    console.log("Users:", users);
  })
  .catch((error) => {
    console.error("Could not load users:", error);
  });

This version explicitly checks the HTTP status and lets the error propagate to the caller, where it can be logged or displayed appropriately.

For production applications, you would normally show users a helpful message while recording enough diagnostic information for developers to investigate the issue. Be careful not to expose access tokens, passwords, or other sensitive information in logs.

Good error handling isn’t about making errors disappear. It’s about making failures understandable and recoverable.

6. The Browser Sends a Different Request Than You Expected

Headers are easy to overlook because most requests work without much manual configuration.

But APIs often expect specific headers for authentication, content negotiation, or request-body parsing.

For example, consider a JSON POST request:

async function createUser() {
  const response = await fetch(
    "https://api.example.com/users",
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify({
        name: "Kapi",
        email: "kapi@example.com"
      })
    }
  );
if (!response.ok) {
    throw new Error(
      `Failed to create user: ${response.status}`
    );
  }
  return response.json();
}

Notice two things.

First, the request specifies Content-Type: application/json, telling the server how to interpret the request body.

Second, the JavaScript object is converted into a JSON string using JSON.stringify(). Passing an ordinary JavaScript object directly as the body of a fetch() request doesn't automatically serialize it into JSON.

If your backend expects JSON but receives a different content type or malformed body, it may reject the request or parse it incorrectly.

You should also avoid setting headers unnecessarily. For example, when sending FormData for a file upload, don't manually set the multipart Content-Type header. The browser needs to generate the boundary parameter itself.

Once again, the Network tab is your friend. Compare the headers and request body from Postman with those from the browser. Small differences can explain surprisingly large problems.

7. The Request Works Locally but Fails After Deployment

You finally get everything working on your laptop. You push the code, deploy the application, and discover that the same request fails in production.

Of course it does. Because apparently, the code wasn’t done testing you yet.

One common cause is an incorrect API base URL.

During development, your frontend might call:

fetch("http://localhost:5000/users");

That works because your backend is running on your own machine.

But once the frontend is deployed, localhost refers to the machine running the browser—not your deployed backend. A visitor opening your website will attempt to connect to their own computer.

The solution is to configure the correct API URL for each environment.

For example, with a frontend build tool that supports VITE_ environment variables:

const API_BASE_URL = import.meta.env.VITE_API_BASE_URL;
async function getUsers() {
  const response = await fetch(
    `${API_BASE_URL}/users`
  );
  if (!response.ok) {
    throw new Error(
      `Request failed: ${response.status}`
    );
  }
  return response.json();
}

Your development environment might use a local backend URL, while production points to the deployed API.

Keep in mind that frontend environment variables are generally embedded into the client-side application during the build. They are configuration, not a safe place to store private API keys or other secrets.

Deployment can introduce other differences, too: HTTPS requirements, reverse-proxy routing, allowed CORS origins, cookie settings, and environment-specific authentication configuration.

If a request works locally but fails after deployment, compare the actual URLs and browser-visible configuration in both environments before assuming your application logic is broken.

8. My Practical Debugging Checklist

When an API works in Postman but fails in the frontend, I try to investigate in a consistent order rather than changing five things at once.

First, inspect the browser request. Open DevTools, go to Network, reproduce the problem, and check whether the request was sent. If it wasn’t, investigate the frontend code and browser console.

Second, compare it with Postman. Check the URL, HTTP method, query parameters, request body, headers, cookies, and authentication. Make sure you’re comparing equivalent requests.

Third, interpret the failure. A 401 suggests an authentication issue; a 403 suggests an authorization problem; a 404 may indicate the wrong route; and a 500 points toward a server-side failure. These are clues, not absolute rules. A CORS error may also prevent JavaScript from seeing the actual response details.

Fourth, check CORS and preflight behavior. If the browser reports a cross-origin error, inspect the response headers and any OPTIONS request. Verify that the server permits the actual origin, method, and headers required by the frontend.

Fifth, inspect the response body. If the status is successful, check whether the JSON structure matches what your JavaScript expects. Look for missing fields, unexpected arrays or objects, and nullable values.

Finally, verify the environment. Confirm the deployed API URL, HTTPS configuration, cookies, authentication settings, and server routing.

This process won’t identify every possible bug automatically, but it gives you a logical starting point. More importantly, it helps you avoid randomly modifying working code and accidentally creating a second problem while trying to fix the first.

The Real Lesson: Postman Tests the API, Not Your Entire Application

Postman is an excellent tool for testing endpoints, inspecting responses, experimenting with headers, and verifying authentication flows. If an API works there, that’s useful evidence that the endpoint can handle at least that particular request.

But a browser-based application introduces additional conditions. Your frontend runs under a particular origin, browser security rules apply, credentials may behave differently, and your JavaScript must correctly process the response and update the interface.

A successful Postman request proves neither that the browser will be allowed to read the response nor that your frontend will interpret it correctly.

The next time your API works in Postman but fails in your application, resist the urge to rewrite the backend immediately. Open DevTools, inspect the request, compare the evidence, and identify exactly where the behavior starts to differ.

Sometimes the problem really is CORS. Sometimes it’s a missing token, an unexpected response shape, or a URL that still points to localhost.

And sometimes, after an hour of investigation, the entire mystery turns out to be one missing header.

Web development keeps us humble like that.

But once you learn to debug requests systematically, these problems become much less mysterious — and your coffee has a better chance of staying warm.

Your API Works in Postman. Why Is Your Frontend Still Broken? was originally published in All About Computers on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few days ago, I was looking at a JavaScript program that seemed to be doing everything at once.

It was fetching data from an API, responding to button clicks, updating the page, and running a few asynchronous operations in the background. Somehow, the interface remained responsive instead of freezing every time the application had to wait for something.

That made me wonder: if JavaScript runs on a single main thread in the browser, how does it manage all this without getting stuck?

I already knew about async/await and promises. I had used them in projects, fixed a few errors with them, and occasionally stared at a rejected promise wondering where my afternoon had gone. But knowing how to use asynchronous code and understanding what happens behind the scenes are two very different things.

The answer turned out to be more interesting than I expected. JavaScript doesn’t magically execute everything simultaneously. Instead, the runtime coordinates execution, delegates certain operations to the surrounding environment, and uses an event loop to decide what runs next.

Once I understood that, several confusing JavaScript behaviors suddenly made sense.

First, What Does Single-Threaded Actually Mean?

When we say JavaScript is single-threaded, we’re usually talking about execution on the main JavaScript thread in a browser. In the conventional model, that thread executes one JavaScript task at a time. It has a call stack, and functions are pushed onto that stack when called and removed when they finish.

Consider this simple example:

console.log("First");
function greet() {
  console.log("Second");
}
greet();
console.log("Third");

The output is predictable:

First
Second
Third

JavaScript doesn’t jump to the last line and then return to the function whenever it feels like it. It follows the execution flow, calling functions and completing them in order.

When greet() is called, its execution is placed on the call stack. Once the function finishes, it is removed, and execution continues with the next statement.

So far, nothing surprising.

But what happens when a function needs to wait for a network response that might take 200 milliseconds — or two seconds? Does JavaScript sit there doing nothing until the server responds?

If it did that for every network request, our web applications would feel painfully slow. Thankfully, the browser provides more than just a JavaScript engine.

The Browser Does More Than Run JavaScript

One of the most useful things to understand is that JavaScript and the browser runtime work together, but they aren’t the same thing.

The JavaScript engine executes JavaScript code. The browser provides additional capabilities, including networking, timers, event handling, and rendering. Some operations can proceed outside the main JavaScript execution thread, allowing the browser to keep doing useful work while JavaScript isn’t actively executing that particular operation.

Let’s see what that means with a timer.

console.log("Start");
setTimeout(() => {
  console.log("Timer finished");
}, 1000);
console.log("End");

The output is:

Start
End
Timer finished

Wait a second. Literally.

Why didn’t JavaScript wait for the timer to finish before printing "End"?

When the runtime encounters setTimeout(), it registers the timer with the host environment. JavaScript continues executing the remaining statements rather than blocking the main thread for a second.

Once the timer becomes eligible to run, its callback can be scheduled for execution. The callback doesn’t interrupt JavaScript in the middle of another task; it waits until the runtime can run it.

There’s a subtle detail here: setTimeout(callback, 1000) does not guarantee that the callback runs exactly one second later. It specifies a minimum delay before the callback becomes eligible to run. If the main thread is busy, the callback may execute later.

That distinction matters when you’re building real applications.

Meet the Call Stack: Where JavaScript Gets Its Work Done

Before we talk about the event loop, let’s spend a moment with the call stack.

Imagine Kapi is building a small shopping application. When a user clicks the checkout button, the application calls a function that validates the cart, calculates the total, and prepares an order.

Each function call adds a frame to the call stack. When the function returns, that frame is removed. The stack keeps track of what JavaScript is currently executing and where it should continue afterward.

Here’s a tiny example:

function calculateTotal() {
  return 100 + 50;
}
function checkout() {
  const total = calculateTotal();
  console.log(total);
}
checkout();

The execution moves through checkout(), then calculateTotal(), and back to checkout() before printing the result.

The important point is that ordinary synchronous JavaScript runs to completion before the runtime moves on to another task. The event loop doesn’t jump into a new callback halfway through a function just because a timer has expired.

This also explains why an expensive loop can freeze a page. If JavaScript spends several seconds performing CPU-heavy work on the main thread, the browser may struggle to respond to clicks, process callbacks, or render updates until that work yields control.

Single-threaded execution is straightforward, but it means we need to be careful about blocking the main thread.

The Event Loop Is the Coordinator

Now we get to the part that connects everything together.

The event loop is a mechanism in the JavaScript host environment that coordinates when queued work gets an opportunity to execute. It doesn’t make a single JavaScript thread execute several callbacks simultaneously. Instead, it helps schedule work so the thread can handle different tasks over time.

A simplified mental model looks like this:

1. JavaScript executes the current task.
2. The host environment handles operations such as timers and network activity.
3. When callbacks become eligible, they are queued according to the relevant scheduling rules.
4. After the current JavaScript execution finishes, the runtime processes pending microtasks at the appropriate checkpoint.
5. The browser can then proceed with rendering and other event-loop work as needed.

The actual browser event loop has more details, including different task sources and rendering opportunities, but this model is enough to understand many everyday JavaScript behaviors.

One detail is worth remembering: the event loop is not a magical background thread that executes your queued JavaScript. The callback still needs time on the JavaScript thread when its turn arrives.

That’s why asynchronous code can improve responsiveness without making CPU-heavy JavaScript calculations automatically faster.

Tasks vs. Microtasks: Why Promise Callbacks Run First

This is where JavaScript starts getting really interesting.

Not all scheduled callbacks are handled through the same queue. In browser environments, tasks and microtasks have different scheduling rules.

Timer callbacks and many event callbacks are associated with tasks. Promise reactions, such as the callbacks registered through .then(), are scheduled as microtasks. Microtasks are processed at microtask checkpoints, including after the current task's JavaScript execution completes, before the browser proceeds to its next task.

Let’s look at a program that used to confuse me:

console.log("A");
setTimeout(() => {
  console.log("B");
}, 0);
Promise.resolve().then(() => {
  console.log("C");
});
console.log("D");

What do you think the output will be?

If you guessed A, B, C, D, you're not alone. I initially expected the timer callback to run immediately because its delay was zero.

But the actual output is:

A
D
C
B

Here’s why.

First, "A" is printed. JavaScript executes the first statement synchronously.

Next, the timer is registered. The callback doesn’t execute immediately. It becomes eligible to run according to the timer and task-scheduling rules.

Then, the promise callback is scheduled as a microtask. Because the promise is already fulfilled, the .then() reaction becomes eligible to run at the next microtask checkpoint.

Finally, "D" is printed. The current synchronous JavaScript finishes before the runtime moves on to the pending microtask.

At the microtask checkpoint, "C" is printed. Once the microtask queue has been drained, the event loop can proceed to the timer task, which prints "B".

This is the reason the promise callback runs before the timer callback in this example.

The 0 in setTimeout(..., 0) doesn't mean "run right now." It means the callback can become eligible after the minimum delay, subject to scheduling rules and the current state of the event loop.

Once you understand tasks and microtasks, output-order questions become much easier to reason about.

What About async and await?

At this point, you might be wondering whether async/await changes the rules.

It doesn’t. It gives us a more readable way to work with promises.

Consider this example:

async function getData() {
  console.log("Inside function");
const result = await Promise.resolve("Data received");
  console.log(result);
}
console.log("Start");
getData();
console.log("End");

The output is:

Start
Inside function
End
Data received

The interesting part is that getData() begins executing immediately. It prints "Inside function" before reaching the await expression.

When execution reaches await, the function suspends until the awaited promise settles. The surrounding JavaScript doesn't have to stop and wait for the function to resume. It continues to the next statement and prints "End".

Because the promise in this example is already fulfilled, the continuation can resume through promise-related microtask scheduling after the current synchronous execution finishes.

That’s why "Data received" appears last.

One important distinction: await doesn't necessarily mean a network request is happening, and it doesn't automatically move work to another thread. It pauses the execution of the current async function while allowing the surrounding JavaScript to continue.

If you await a promise representing a network request, the network operation is handled by the host environment. When the response is available and the promise settles, the function can resume.

And yes, you can still block the main thread inside an async function if you run expensive synchronous code before yielding. Adding the async keyword doesn't make CPU-heavy calculations magically asynchronous.

The Event Loop Doesn’t Make Heavy Computation Free

Here’s a mistake that’s easy to make when learning asynchronous JavaScript: assuming that because the event loop handles asynchronous operations, it can also make expensive computations run without blocking the page.

Imagine this:

console.log("Starting");
let total = 0;
for (let i = 0; i < 1_000_000_000; i++) {
  total += i;
}
console.log("Finished");

The loop runs synchronously on the thread executing it. Until it completes, JavaScript can’t process another task on that same thread.

If this code takes several seconds, the page can become unresponsive. Clicking a button won’t cause its handler to interrupt the loop, and a timer callback won’t jump in to execute halfway through.

You could try wrapping the loop in a promise or declaring the surrounding function async, but that alone wouldn't solve the problem. The heavy computation would still run synchronously.

For CPU-intensive work, a browser Web Worker may be a better choice. A worker runs JavaScript in a separate worker thread with its own execution context. It can perform calculations without blocking the main thread in the same way, although communication and data transfer still have costs.

For example, a worker could calculate a large dataset and send the result back to the main thread. The main thread would remain available for interface work while the worker handled the calculation.

For network requests, timers, and many I/O operations, the host environment’s asynchronous APIs are usually enough. For substantial CPU-bound work, consider a worker or another approach that divides the work into manageable chunks.

The right solution depends on what is actually taking the time.

A Practical Example: Fetching Data Without Freezing the Page

Let’s bring these ideas into a more realistic situation.

Suppose you’re building a dashboard that loads user information from an API. You want to show a loading message, display the results when the request succeeds, and handle failures gracefully.

Here’s a simple example:

async function loadUsers() {
  const status = document.querySelector("#status");
  const list = document.querySelector("#users");
status.textContent = "Loading users...";
  list.replaceChildren();
  try {
    const response = await fetch(
      "https://jsonplaceholder.typicode.com/users"
    );
    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }
    const users = await response.json();
    for (const user of users) {
      const item = document.createElement("li");
      item.textContent = user.name;
      list.appendChild(item);
    }
    status.textContent = "Users loaded successfully.";
  } catch (error) {
    status.textContent = "Could not load users.";
    console.error("Failed to load users:", error);
  }
}
loadUsers();

This example assumes the page contains elements with IDs status and users. The endpoint is a public demonstration API; in a real application, you'd use your own endpoint and handle its specific requirements.

Here’s what happens behind the scenes.

First, the function updates the interface to show that the request has started. Then fetch() initiates a network request through the browser's networking facilities and returns a promise.

When JavaScript reaches the first await, the function suspends while the surrounding execution can continue. The browser can handle other work while the request is in progress.

Once the response becomes available, the promise settles and the function resumes. The code checks response.ok because fetch() does not automatically reject for HTTP error responses such as 404 or 500. It then reads the response body, creates list items, and updates the status message.

If the request fails or the code throws an error, the catch block handles it.

Notice what we haven’t done: we haven’t created a separate JavaScript thread just to fetch users. We’ve used an asynchronous API and promise-based scheduling to avoid blocking the main thread while waiting for the network.

For a small list, rendering the results one by one is perfectly reasonable. For thousands of items, however, rendering and DOM updates could become expensive. At that point, you’d investigate pagination, virtualization, or other performance improvements.

Understanding the event loop helps you recognize both what asynchronous programming solves and what it doesn’t.

A Few Things Worth Remembering

After understanding the call stack, host environment, tasks, microtasks, and promises, I started looking at JavaScript in a slightly different way.

When a callback runs later, it isn’t because JavaScript has been secretly executing it in the background. It’s because the runtime has scheduled it to run when the thread becomes available.

When a promise callback runs before a timer callback, it’s because microtasks and tasks follow different scheduling rules.

And when a page freezes during a long calculation, it’s because the main thread is busy doing synchronous work and cannot process other JavaScript tasks until it gets a chance to continue.

These distinctions are useful when debugging race conditions, understanding asynchronous output, designing responsive interfaces, and figuring out why a supposedly asynchronous operation still makes a page feel slow.

You don’t need to memorize every browser scheduling detail before you can build useful applications. Start by predicting what a small program will print, then run it and compare the result with your reasoning. Try changing a timer to a promise, adding an await, or introducing a synchronous loop. Those tiny experiments can teach you more than reading ten explanations in a row.

JavaScript Isn’t Doing Everything at Once. It’s Taking Turns Well.

The more I learned about the event loop, the less mysterious JavaScript’s asynchronous behavior became.

The main JavaScript thread still has to execute code one piece at a time. But the runtime coordinates timers, network operations, promise reactions, and other scheduled work so the application can respond to events instead of waiting synchronously for everything to finish.

That design is powerful, but it also places responsibility on us as developers. We need to understand when code blocks the main thread, how asynchronous operations resume, and why different callbacks don’t always execute in the order we first expect.

The next time a promise prints before a timer or an interface freezes during a calculation, you’ll have a better idea of what’s happening behind the scenes.

And honestly, that’s one of my favorite things about learning JavaScript: behavior that once looks like magic eventually turns into something you can explain, test, and use deliberately.

Which is much more satisfying than randomly changing the code until the output looks right.

JavaScript Is Single-Threaded. So How Does It Handle So Much at Once? was originally published in All About Computers on Medium, where people are continuing the conversation by highlighting and responding to this story.

I used to think the frontend was where most of the interesting things happened. You build a beautiful interface, connect a few buttons, fetch some data, and suddenly you have an application that feels alive. Then you start working on something slightly more complicated, like user authentication or saving data, and you realize that the frontend is only showing one part of a much bigger system. The button might look perfect, but what happens after someone clicks it is an entirely different story.

I remember how easy it was to think of the backend as a place where requests went, data came from, and mysterious server things happened in between. I could call an API, receive a JSON response, and move on with my day without thinking too much about what happened behind the scenes. That approach worked until something broke. Suddenly, I needed to understand why a request returned a 401, why the server couldn't find a record, or why the same endpoint behaved differently depending on who was logged in.

The more I learned about backend development, the more I realized that frontend developers don’t need to become backend experts, but understanding the fundamentals changes how they build applications. It becomes easier to debug issues, design better interfaces, communicate with backend developers, and avoid assumptions that create bugs later. So, if you’ve ever wondered what actually happens after your frontend sends a request, here are seven backend concepts worth understanding.

1. APIs: How Your Frontend Talks to the Backend

An API, or Application Programming Interface, is one of the first backend concepts a frontend developer encounters. Whenever your application loads a profile, retrieves a list of products, or submits a login form, it often communicates with a backend through an API. You send a request containing information about what you need, and the server processes that request before returning a response. The frontend then uses the response to update the interface.

Imagine you’re building a shopping application. When someone opens the products page, the frontend might request a list of available products from an endpoint such as /api/products. The server receives the request, retrieves the relevant information, and returns a response containing product names, prices, and identifiers. Your frontend doesn't need to know exactly how the database stores those products. It only needs to understand the API contract, including the request format and the structure of the response.

A simple JavaScript example might look like this:

async function getProducts() {
  const response = await fetch("/api/products");
  if (!response.ok) {
    throw new Error("Failed to fetch products");
  }
  return response.json();
}

This function sends an HTTP request, checks whether the response indicates success, and parses the response body as JSON. Notice that fetch() does not automatically throw an exception for HTTP errors such as 404 or 500, which is why checking response.ok matters. Network failures can still reject the promise, so production code should also handle those failures and display an appropriate loading, success, or error state.

The important thing to understand is that an API is a contract between two parts of a system. If the backend changes a field from productName to name without updating the contract or coordinating the change, your frontend might suddenly display empty product titles. Good API design makes those expectations explicit, while good frontend code avoids assuming every request will succeed. Once you understand APIs this way, debugging becomes less about randomly changing components and more about identifying which part of the contract has failed.

2. HTTP Methods and Status Codes: Understanding What a Request Means

When I first started working with APIs, I mostly cared about whether the request worked. If I received data, everything was fine; if I received an error, something was broken. But HTTP methods and status codes provide important information about what the client is asking the server to do and how the server handled that request. Understanding them makes it much easier to design frontend behavior that matches what the backend actually supports.

Consider a simple application that manages user profiles. A GET request might retrieve a profile, a POST request might create a new resource, a PATCH request might update part of an existing resource, and a DELETE request might remove a resource. These methods communicate intent, although the exact behavior depends on the API's design. PUT is commonly used to replace a resource representation, while PATCH is commonly used for partial updates.

Here is a small example using JavaScript:

async function updateProfile(profileId, changes) {
  const response = await fetch(`/api/profiles/${profileId}`, {
    method: "PATCH",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(changes)
  });
  if (!response.ok) {
    throw new Error(`Request failed: ${response.status}`);
  }
  return response.json();
}

The request sends a partial update to a profile endpoint. The Content-Type header tells the server that the request body contains JSON, and JSON.stringify() converts the JavaScript object into a JSON string. The backend still needs to validate the submitted values, verify permissions, and decide what response to return. Sending a request successfully does not automatically mean the update was valid or authorized.

Status codes help explain the outcome. A 200 generally indicates success, 201 commonly indicates that a resource was created, 400 often indicates an invalid request, 401 indicates missing or invalid authentication credentials, and 403 means the server understood the request but refuses to authorize it. A 404 indicates that the requested resource was not found, while 500 signals an unexpected server-side failure. These meanings have specific HTTP definitions and can be used differently within a particular API's documented behavior.

For frontend developers, these distinctions directly affect user experience. An invalid form might need field-level validation messages, an expired session might require the user to sign in again, and a server failure might justify a retry option. Treating every unsuccessful response as “Something went wrong” throws away useful information. Understanding HTTP gives you a better way to connect backend behavior with meaningful feedback in the interface.

3. Databases: Where Your Application’s Data Actually Lives

A frontend can display information beautifully, but it usually shouldn’t be responsible for permanently storing important application data. When someone creates an account, saves a favorite product, or submits an order, the backend typically coordinates with a database to store and retrieve that information. Understanding this relationship helps explain why a successful button click doesn’t necessarily mean the data has been saved, and why data displayed in the browser can sometimes become outdated.

There are several database models, but relational databases are a useful starting point. Systems such as PostgreSQL and MySQL organize data into tables containing rows and columns, with relationships connecting related records. A shopping application might store users in one table, products in another, and orders in a third. Each table has its own structure, and the backend uses queries to retrieve or modify records according to the application’s requirements.

For example, a backend might execute a query like this:

SELECT id, name, email
FROM users
WHERE id = 42;

This query retrieves selected fields for a user whose identifier is 42. The frontend usually shouldn't connect directly to the production database or decide how this query is executed. Instead, it requests a profile through an API, and the backend checks permissions, performs the query safely, and returns the information the current user is allowed to access. Keeping database access behind the backend provides a controlled place to enforce business rules and security.

Databases also explain why frontend data can become stale. Imagine that a user changes their display name in one browser tab while another tab still shows the previous value. The second tab may be displaying cached data or simply may not have fetched the updated record yet. The database can contain the correct value even while the interface displays something older. Refreshing data, updating local state carefully, and handling failed saves are therefore important parts of frontend development.

One more thing worth understanding is that databases have schemas and constraints. A column might be required, an email address might need to be unique, or an order might reference an existing user. These rules protect data integrity, even when requests arrive from different clients. Frontend validation is useful for helping people correct mistakes before submitting a form, but the backend and database must still enforce the rules because clients can send unexpected or deliberately manipulated requests.

4. Authentication and Authorization: Who Are You, and What Can You Do?

Authentication and authorization sound similar, and I definitely understand why developers sometimes mix them up. Authentication answers the question, “Who are you?” Authorization answers, “What are you allowed to do?” They work together, but they solve different problems. A user might successfully sign in to an application and still have no permission to access another user’s private documents or perform administrative actions.

Imagine you’re building a dashboard with separate views for customers and administrators. After a customer signs in, the application needs some way to establish the user’s identity for subsequent requests. Depending on the architecture, the backend might use a server-side session identified by a cookie or a token-based mechanism. The frontend can use that authentication state to show the appropriate interface, but the backend must independently verify the credentials and permissions whenever a protected operation is requested.

A simplified frontend request might look like this:

const response = await fetch("/api/my-profile", {
  credentials: "include"
});

The credentials: "include" option allows the browser to include applicable credentials, such as cookies, with the request, subject to browser rules, cookie attributes, and CORS configuration. This is commonly useful when an application uses cookie-based sessions. The backend then validates the session and determines which user the request belongs to. For cross-origin requests, the server must also configure credentialed CORS correctly, and the cookie settings must be compatible with the deployment.

The security boundary is the important part. Hiding an admin button in the frontend does not prevent someone from calling the administrative API directly. A malicious user can inspect network requests, modify client-side code, or send requests using tools outside the browser. The backend must verify authorization before performing protected actions, even when the frontend already hides the corresponding controls. Client-side checks improve usability, but they are not a substitute for server-side enforcement.

Authentication also comes with practical security concerns. Passwords should never be stored as plain text, session identifiers must be protected, and sensitive tokens should not be exposed casually through logs or browser storage. Cookie-based authentication may require appropriate CSRF protections, while token-based systems have their own storage, expiration, and revocation trade-offs. You don’t need to design an entire identity system as a frontend developer, but understanding these basics helps you recognize why authentication bugs can be much more serious than ordinary UI bugs.

5. Middleware and Validation: What Happens Before Your Request Reaches the Main Logic?

When a request reaches a backend, it doesn’t always go directly to the function that handles the requested feature. Many applications run requests through middleware or similar processing layers first. These layers can perform tasks such as request logging, authentication checks, rate limiting, parsing request bodies, and handling cross-origin rules. Understanding middleware helps explain why a request might fail before the endpoint’s main logic ever runs.

Imagine a frontend sends a request to update a profile, but the server responds with 401 Unauthorized. You might immediately suspect that the profile endpoint is broken, even though the request may never have reached the profile-handling function. Authentication middleware could have rejected it because the session cookie was missing or expired. Looking at the request headers, browser network panel, and backend logs can help determine whether the failure happened during authentication or inside the endpoint itself.

Validation is another important part of the process. Frontend forms can prevent many mistakes by checking required fields, email formats, and acceptable input ranges. However, a backend must validate incoming data independently because requests can come from mobile applications, scripts, automated clients, or modified browser requests. If an API expects a positive quantity, it should reject invalid values even if the normal frontend never allows a user to submit them.

For example, a simplified backend validation function might look like this:

def validate_quantity(quantity):
    if not isinstance(quantity, int) or quantity < 1:
        raise ValueError("Quantity must be a positive integer")
    return quantity

This example checks that the quantity is an integer of at least one, although a production API would normally convert validation failures into a structured client error such as 400 Bad Request or 422 Unprocessable Content, depending on its conventions. It should also account for how incoming JSON values are parsed and how validation errors are returned. The key principle is that the backend must enforce the rules rather than trusting that the frontend has already done so.

Middleware and validation become especially useful to understand when errors appear inconsistent. Perhaps one endpoint works while another returns 403, or a request is rejected before your handler can log anything. Rather than assuming the business logic is wrong, investigate the request pipeline. Knowing what runs before the endpoint gives you a much better mental model of how backend applications process incoming requests.

6. Caching: Why the Data You See Might Not Be the Latest Data

Caching is a technique for storing a reusable copy of data so that future requests can be served more quickly or cheaply. Instead of recalculating a result or retrieving the same information from a database every time, an application may temporarily reuse an earlier response. Caching can improve performance and reduce infrastructure costs, but it also introduces a question frontend developers eventually encounter: what happens when the original data changes while a cached copy still exists?

Imagine a product page that displays a price retrieved from an API. The backend might cache product information for a short period to reduce database load, while the browser might also cache the HTTP response. If the product’s price changes, the interface could continue displaying the older value until the relevant cache expires or is invalidated. The application isn’t necessarily broken; different layers are temporarily working with different versions of the data.

HTTP caching headers help control some of this behavior. For example, a server might return:

Cache-Control: max-age=60

This tells compatible caches that the response can generally be considered fresh for up to 60 seconds, subject to the applicable HTTP caching rules. It doesn’t mean every cache will necessarily store the response, nor does it guarantee that all application data will update exactly one minute later. Authentication, cache directives, browser behavior, and intermediary infrastructure can affect the outcome, so caching policies need to be chosen according to the sensitivity and freshness requirements of the data.

Caching is especially useful for content that changes infrequently, such as public documentation, static assets, or product catalog information. It needs more careful handling for data that changes frequently or must reflect current state, such as account balances, inventory, or order status. A frontend might also cache API responses in application state or a data-fetching library, which means updating the server alone may not immediately update the visible interface.

The important lesson is that stale data can originate from several layers. If an update appears successful but the old value remains on screen, check whether the backend returned the new value, whether the browser is reusing a cached response, and whether your frontend state was updated. Understanding caching gives you more ways to investigate the problem without immediately assuming that the database failed to save the change.

7. Background Jobs and Queues: Not Everything Happens During the Request

One of the most useful backend concepts to understand is that not every operation should happen while a user is waiting for an HTTP response. Some tasks take longer than a normal request should reasonably take, such as sending large batches of emails, generating reports, processing uploaded files, or coordinating with slow external services. In those cases, a backend can place the work into a queue and let a background worker process it separately.

Imagine a user uploads a video to your application. If the backend tries to upload the file, transcode it, generate thumbnails, and update every related record before responding, the request might take too long or time out. A more practical design can store the uploaded file, create a processing job, and return a response indicating that processing has started. A background worker then performs the expensive work and updates the job’s status when it finishes.

A simplified API response might look like this:

{
  "jobId": "job_123",
  "status": "processing"
}

The frontend can use this information to show a progress indicator or a message explaining that the task is still running. It might poll a status endpoint periodically, subscribe to server-sent events, or use a WebSocket if the application needs more immediate updates. The right approach depends on the product’s requirements, infrastructure, and expected volume of work. The important part is that the initial request doesn’t have to remain open until every background operation is complete.

Queues also introduce behaviors that frontend developers should understand. A task can remain pending, fail, retry, or take longer than expected, so a response indicating that processing started should not be presented as proof that the task succeeded. The interface needs to distinguish between states such as queued, processing, completed, and failed. If the user leaves the page and returns later, the application may need to retrieve the job’s current status instead of relying on temporary component state.

There is also a reliability consideration: background jobs may run more than once, depending on the queue and retry strategy. For operations such as sending payments or creating orders, the backend often needs idempotency or other safeguards to avoid duplicate effects. As a frontend developer, you don’t necessarily need to implement the worker yourself, but knowing that asynchronous processing exists helps you design interfaces that communicate progress accurately instead of leaving users wondering whether their action did anything.

Putting These Concepts Together

Let’s bring everything together with a familiar example: a user signing in to a web application. The frontend sends an HTTP request to an authentication API, the backend validates the request, authentication logic checks the submitted credentials, and the server establishes an appropriate session or token-based authentication state. If the user is authorized to access their profile, the backend retrieves the relevant database record and returns a response that the frontend can use to render the page.

Even this seemingly simple flow involves several of the concepts we’ve discussed. The API defines the request and response contract, HTTP status codes communicate success or failure, the database stores the user’s information, and middleware may validate the session before the endpoint runs. Caching might affect how profile information is retrieved, while background jobs could handle tasks such as sending a welcome email. Understanding these relationships makes it easier to reason about the whole application rather than treating every problem as a frontend bug.

When something goes wrong, the same mental model gives you a practical debugging path. If a request returns 401, investigate authentication and session handling. If the response contains unexpected values, check the API contract and database data. If an operation appears successful but takes time to finish, find out whether the backend processes it asynchronously. Instead of randomly changing components, you can identify which layer is responsible and collect evidence before deciding what to fix.

You don’t need to memorize every backend framework or become an expert in database administration to benefit from these ideas. Start by understanding the request lifecycle in the applications you already build. Open the browser’s Network panel, inspect request headers and responses, read the API documentation, and ask what the backend is doing behind each important user action. Those small habits will gradually turn backend behavior from a mystery into something you can reason about confidently.

You Don’t Need to Build the Backend to Understand It

I used to think understanding the backend meant learning an entirely separate world of technologies before I could become a better frontend developer. Now I see it differently. You don’t have to write every database query or configure every server to benefit from understanding APIs, HTTP, authentication, validation, caching, and background processing. You just need enough knowledge to understand how the pieces connect and where responsibility belongs when something goes wrong.

That understanding changes the way you build interfaces. You start accounting for loading states, expired sessions, validation errors, stale data, and tasks that take time to complete. You stop assuming that a successful click guarantees a successful operation, and you become more careful about which checks belong in the frontend and which must be enforced by the backend. Your code becomes more resilient because you’re designing for the behavior of a real system, not just the happy path shown in a tutorial.

My advice is to choose one application you’re already working on and trace a single feature from beginning to end. Follow the button click, inspect the API request, examine the response, and find out how the backend stores or retrieves the data. When you encounter a concept you don’t understand, investigate it with a small example instead of trying to learn an entire technology stack at once. You’ll build a much stronger mental model by connecting each concept to something you’ve actually seen happen.

The best frontend developers don’t need to know everything about the backend, but they benefit enormously from understanding what happens beyond the browser. Once those invisible parts of the application start making sense, debugging becomes less intimidating, collaboration becomes easier, and building reliable features becomes a much more deliberate process. And honestly, that’s a pretty good reason to spend a little time learning what happens after the request leaves your laptop.

7 Backend Concepts Every Frontend Developer Should Understand was originally published in All About Computers on Medium, where people are continuing the conversation by highlighting and responding to this story.

A while back I was building a checkout service, and for the first few weeks I hardly tested a thing. I’d love to say that was a choice. It wasn’t. The payments API I needed? Another team was still building it. Inventory lived in a staging setup with an uncanny habit of going down exactly when I sat down to test. So my workflow was basically: write code, open a PR, hope. Not my proudest stretch.

So what changed? Honestly, it took me a while to see that API testing and service virtualization go together. I’d always filed them as two separate things in my head, one for QA folks and one for… I wasn’t even sure who. Turns out they’re the same habit. If I can run a convincing fake of a dependency on my laptop, I can test against it, and then nobody else’s schedule decides when I get to find my bugs. I’ll walk through how that played out, because it ended up being less about tools and more about how I thought about the services around mine.

Blocked by APIs that weren’t ready yet

If you’ve worked on a team that splits services across squads, you probably know the feeling. Your feature is done on your side. You need someone else’s endpoint to exist, or to stay up, before you can prove it works. You ping them on Slack. They’re busy shipping their own stuff. Fair enough.

My first workaround was the obvious one. I hand-wrote little fake responses inside my tests, a dictionary here, a hardcoded JSON blob there. It kind of worked. But I was basically guessing at what the payments team would return, and every time they tweaked their design I had to go hunting through my tests to update the guesses.

Virtualizing a dependency from its API contract

Things got better the day I asked the payments team for their OpenAPI spec. They had one, half finished, sitting in their repo. Nobody had thought to share it.

That spec turned out to be gold. I pointed a service virtualization tool at it and, a minute later, had my own little stand-in payments API answering on localhost. Its responses matched the spec field for field. My checkout service had no idea it wasn’t the real one. Neither did my API tests, which finally had something solid to hit. And when the payments team changed a field? They updated the spec, I regenerated the fake, and my tests yelled at me right away about whatever broke.

Honestly, the bigger win was social. Our two teams got into the habit of hashing out the contract first, before anybody even opened an editor. I’d bet that saved us more Slack threads than every tool put together.

Testing the unhappy paths on purpose

Here’s something I didn’t expect. A virtual service is better than the real one at certain kinds of testing.

Ever tried to get a real payments sandbox to time out right when you want it to? Or throw a 429 at you on purpose? Good luck. The virtual one was a lot more cooperative. Slow responses, outright failures, a strange half-empty body, I could dial up whichever one I needed that afternoon. That’s how I found out my retry logic was retrying things it absolutely shouldn’t, like a charge that had already gone through. Would’ve been a fun one to discover in production.

When the real service finally shipped

Eventually the payments API went live in staging. This is the part people sometimes skip, and it matters. Virtual services are only as good as their match with reality, so the first thing I did was run my API tests against the real thing too, and compare.

A couple of small differences showed up. A date format here, an extra nullable field there. Nothing dramatic, and because the contract was shared, fixing the spec fixed both sides at once.

Recording real traffic instead of writing mocks

Once the real services existed, I didn’t want to keep maintaining virtual services by hand forever. That’s where record-and-replay came in.

The tool I ended up liking for this was Keploy. It’s open source, and it uses eBPF to capture traffic at the kernel level, so I didn’t have to change a line of my service’s code. I ran checkout through it, clicked through a few real purchase flows in staging, and it saved the incoming requests as API tests and every outgoing call (payments, inventory, even the database queries) as mocks. After that, my test suite could replay all of it without any of those services being up.

That felt like the natural next step after the spec-based setup. The contract got me unblocked early. Recordings kept my tests honest once real traffic existed.

How it changed the way our teams work together

I used to feel a bit helpless waiting on other teams. Now my default move with any new dependency is pretty simple: get the contract, virtualize it, and start testing that same day. The other team keeps building at their own pace, and nobody’s blocking anybody.

It also made our conversations better. Instead of “is your API ready yet?”, it became “hey, my tests caught a mismatch between your spec and staging, want to take a look?” Way nicer message to send. And to receive, I’d guess.

Conclusion

If I could go back and tell my earlier self one thing, it’d be that waiting on other teams was never really a scheduling problem. It was a testing problem, and it had a fix. Pairing API testing and service virtualization meant my feedback loop was mine again. Whatever state the other teams’ code was in, I could still find out today whether mine worked.

Stuck in that spot right now? Don’t try to fix everything at once. Message the team you’re waiting on and ask for their API spec. Unfinished is fine, honestly, mine was. Spin up a fake from it this week, write a test where everything goes right and another where the payment fails, and see how it feels. My guess is the waiting stops bothering you pretty quickly.

Stop Waiting on Other Teams With API Testing and Service Virtualization was originally published in All About Computers on Medium, where people are continuing the conversation by highlighting and responding to this story.