Working of AJAX and its architecture

📖 Theory

Type g, see Garba

FestConnect's final AJAX feature: a live search box. The student types g; before the second letter lands, matching events are already appearing below.

Think about what must happen in those milliseconds: an event fires, a request forms, travels, a server thinks, an answer returns, the list redraws: and the page never blinks.

You own every individual piece now. This lesson choreographs them, because "explain the working of AJAX with architecture" is this paper's most dependable long-answer question.

🪜 Follow along

The AJAX lifecycle (the exam's 7 steps)

1. An event occurs in the page The user types in the search box (keyup), clicks Refresh: any DOM event can start it.
2. JavaScript creates an XMLHttpRequest object var xhr = new XMLHttpRequest(); the runner reports for duty (readyState 0).
3. open() configures, send() dispatches xhr.open("GET", "search.php?q=g", true); xhr.send(); the request departs in the background.
4. The server processes the request The server-side script reads the query, consults its data (a file today, a database in BCA503), and prepares an answer.
5. A response returns (JSON, XML or text) Small: just the data, never a whole page.
6. onreadystatechange fires as states advance The handler is rung through states 2, 3 and finally 4.
7. At readyState 4 + status 200, script updates the DOM JSON.parse(xhr.responseText), then rewrite ONLY the results list: the rest of the page never notices.

📖 Theory

The architecture: what AJAX inserted

The classic model is a 2-party conversation: browser asks, server replies with a whole new page, browser throws the old one away. Every exchange costs a full rebuild.

The AJAX model inserts a middle layer in the browser: the AJAX engine (the XMLHttpRequest object plus your JavaScript). Now the user interface talks to the engine, the engine talks to the server, and the 2 conversations are decoupled:

• UI to engine: instant, local, no waiting
• engine to server: small data messages, in the background

The user never faces the network directly again: that decoupling IS the architecture.

📊 At a glance

Classic vs AJAX architecture

⌨️ Practical

Live search: the whole unit in one page

<!DOCTYPE html>
<html>
<head>
  <script>
    function liveSearch() {
      var q = document.getElementById("box").value;   // step 1: event data
      var xhr = new XMLHttpRequest();                 // step 2
      xhr.onreadystatechange = function() {           // step 6's bell
        if (xhr.readyState == 4 && xhr.status == 200) {
          var events = JSON.parse(xhr.responseText);  // step 7 begins
          var out = "";
          for (var i = 0; i < events.length; i++) {
            out += "<li>" + events[i].name + "</li>";
          }
          document.getElementById("results").innerHTML = out;
        }
      };
      xhr.open("GET", "search.php?q=" + q, true);     // step 3
      xhr.send();                                     // ...and away
    }
  </script>
</head>
<body>
  <input id="box" onkeyup="liveSearch()" placeholder="Search events">
  <ul id="results"></ul>
</body>
</html>

This example runs in Gri-Learn on the web, where you can edit it and see the output.

🧩 Quiz

In the AJAX architecture, what sits between the user interface and the server?

1. Nothing: AJAX connects the UI to the server more directly than before
2. The AJAX engine: the XMLHttpRequest object driven by JavaScript
3. A second, hidden web page that does the reloading invisibly
4. The jQuery library, which is mandatory for AJAX

💭 Think first

Narrate one keystroke

The student types g in the live-search box. Using the 7 steps and the listing, narrate everything from keystroke to visible results, naming each property and method at its moment. Say it aloud, then tap.

⚠️ Watch out

Long-answer pitfalls

Skipping the server step: the middle of the story (server processes, response returns) is where weak answers go vague; name what the server DOES.

Diagram without labels: an unlabeled middle box earns half; write AJAX engine (XMLHttpRequest + JavaScript) on it.

Claiming zero server load: AJAX often means MORE requests (every keystroke!), each far smaller; the saving is per-exchange weight and user time, not server work abolished.

📖 Theory

Unit 4 closes; one question remains

FestConnect now fetches, searches and registers without a single reload: Units 1 through 4 assembled into one living page. But notice who has been silently assumed all along: the server, that box which reads search.php and answers. You have never built one. Unit 5 fixes that with Node.js, where the SAME JavaScript you have written all semester walks over to the server side and answers these very requests.

✅ Summary

Key takeaways

• Lifecycle: event, create XMLHttpRequest, open + send, server processes, response returns, onreadystatechange fires, update the DOM at 4-and-200.
• The AJAX engine (XMLHttpRequest + JS) sits between UI and server: the architecture's inserted middle layer.
• UI-to-engine is instant and local; engine-to-server is small background data messages.
• Servers return data, not pages; scripts repaint only the affected DOM corner.
• AJAX trades page-sized reloads for many small requests: lighter each, not fewer.
• The live-search listing is the whole unit in one page: learn to narrate it.
• Memory hook: event, engine, envelope, answer, repaint.