🔌 How Frontend and Backend Talk

How Frontend and Backend Talk: The conversation between frontend and backend is like the waiter-kitchen relationship in a RESTAURANT: the browser (waiter) carries a request to `/

The conversation between frontend and backend is like the waiter-kitchen relationship in a RESTAURANT: the browser (waiter) carries a request to `/api/v1/bugs`, the server (kitchen) returns JSON, and JS arranges that JSON onto the DOM (the plate). Why should a tester know this bridge? Because when an element will appear in the DOM depends entirely on the speed of this conversation — and WHERE the page is built (in the browser = CSR, on the server = SSR) fundamentally changes locate timing. Java analogy: this bridge is the frontend-side view of the request/response contract you learned on the `/api-testing` page — the same Bug model, now on screen. In QA context: for a bug you call "not visible in the UI", is the root the frontend (render) or the backend (response) — telling them apart comes from reading the Network panel. Throughout this group we bridge to the `/api-testing` page — syntax lives there, "why/when" lives here.

🌐 E1. Browser -> Server: fetch/XHR, the `/api/v1/bugs` Request

Sending a `fetch`/XHR request is like SHIPPING A PACKAGE: you send the package (the request) off, you get a TRACKING NUMBER (a Network panel row), and you follow the package's status ("pending" -> "delivered") through that number. So why should a tester know how to read this panel? Because seeing EXACTLY WHERE a "nothing shows up in the UI" bug got stuck in DevTools -> Network (did the request never go out? did the server return 404/500? did the response come back empty?) lets you DISTINGUISH whether to assign the bug to the frontend or the backend. Java analogy: like the difference between the old `HttpURLConnection` (the callback/blocking-feeling ancestor of XHR) and the modern `HttpClient`/`CompletableFuture` (fetch's Promise-based structure) — the APIs change, but the underlying HTTP mechanics stay the same. In QA context: this page does not teach `fetch`/XHR SYNTAX (see `/api-testing`, `/javascript`); what is learned here is reading the Network panel as a DIAGNOSTIC TOOL.

Step by Step: How a Click Appears in the Network Panel

The user submits "New Bug"

JS gathers the form data and triggers a `fetch('/api/v1/bugs', {method:'POST', body:...})` call.

The request lands in the Network panel

A NEW row appears in DevTools -> Network: `POST /api/v1/bugs`, its status "pending".

The server processes it

As long as this row stays "pending", the server has NOT responded yet — this is the Network-panel counterpart of the race from GROUP D3.

The status code and response arrive

The row UPDATES to "200" (or 4xx/5xx) and the JSON body becomes visible in the response tab.

Bridge for the tester: `/api-testing`

The method/status/body in this row is the frontend-side VIEW of the contract you learned on the `/api-testing` page — you tell whether a bug is in the frontend or the backend by reading the Network panel.