The conversation between browser and Flask uses HTTP — HyperText Transfer Protocol. Every request is a text message sent over the network following a strict format: a method (GET, POST, PUT, DELETE), a URL, headers (metadata about the request), and optionally a body (the data being sent).

Flask is a WSGI application — Web Server Gateway Interface. WSGI is a Python standard that defines how a web server hands a request to a Python application and receives a response back. When you run flask run in development, Flask starts a built-in WSGI server. In production, a dedicated server like Gunicorn or uWSGI takes that role. The Flask application itself does not change — only what sits in front of it.

The conversation between Flask-SQLAlchemy and MySQL uses a separate protocol — the MySQL wire protocol — over a TCP connection to the school MySQL server. Flask-SQLAlchemy (via PyMySQL) opens this connection when your app starts, keeps it in a connection pool, and reuses it for subsequent queries rather than reconnecting every time. This is why your SQLALCHEMY_DATABASE_URI config line contains a hostname, port, username, password, and database name — every field is needed to establish that TCP connection.

fetch is asynchronous — it does not stop JavaScript from running while it waits for the server to respond. Instead, it returns a Promise: a placeholder for a value that will arrive later. The .then() calls register callback functions that run when the promise resolves. This is why you cannot do const data = fetch(...) and then immediately use data — the data hasn't arrived yet. This asynchronous model is fundamentally different from Python's top-to-bottom execution, and it is the source of most JavaScript confusion for Python programmers.

Modern JavaScript allows async/await syntax as an alternative to .then() chains — it makes asynchronous code look synchronous without blocking the browser. You may see both patterns in production code.

The @app.route decorator is syntactic sugar for calling app.add_url_rule(). Flask stores all registered routes in a URL map — a data structure that maps URL patterns to view functions. When a request arrives, Flask uses Werkzeug (the library Flask is built on) to match the incoming URL against that map. Werkzeug supports dynamic segments like /api/students/<int:id>, which capture part of the URL as a function argument.

Each request in Flask runs inside a request context — a temporary object pushed onto a stack at the start of the request and popped at the end. The request object you import from Flask (from flask import request) is a proxy to this context. This is why you can access request.args and request.json inside a route function without passing anything in — Flask makes those objects available automatically during the request lifecycle. It is also why accessing request outside a route function raises a RuntimeError: working outside of request context.

SQLAlchemy has two layers. The Core layer is a SQL expression language — you build SQL programmatically using Python objects, and it generates the query string. The ORM layer (which this course uses) sits on top of Core and adds the model-class abstraction: each class maps to a table, each instance maps to a row.

Queries in the ORM are lazy by default — select(Student) does not hit the database immediately. The query is only executed when you call db.session.execute() and then materialise the results with .scalars().all(). This deferred execution model is what allows SQLAlchemy to optimise and compose queries before sending them.

The session (db.session) is SQLAlchemy's unit-of-work manager. It tracks all objects you have loaded or modified in the current request. When you call db.session.commit(), it writes all pending changes to the database in a single transaction. If anything fails, you call db.session.rollback() to undo all changes atomically. In Flask-SQLAlchemy, the session is automatically scoped to the current request — it is created when a request begins and closed (with a rollback of any uncommitted changes) when the request ends.

jsonify() calls Python's json.dumps() under the hood, with Flask-specific handling for a few types that the standard library cannot serialise by default (like datetime objects). The result is wrapped in a Response object with Content-Type: application/json. This header is important: it tells the browser's fetch API what kind of data to expect, which is why response.json() in JavaScript works without you specifying a format.

The HTTP response itself has three parts: a status line (HTTP/1.1 200 OK), headers (key-value metadata including Content-Type and Content-Length), and a body (the actual JSON string). All of this travels over a TCP connection that the browser opened to the Flask server. HTTP/1.1 can reuse that connection for multiple requests (keep-alive). HTTP/2, used by production servers, multiplexes many requests over a single connection simultaneously. In development with flask run, you are using HTTP/1.1.

For complex bugs that span multiple layers, professionals use tools that give visibility into each layer independently: Flask's debug toolbar shows timing, SQL queries executed, and request/response details inline in the browser. SQLAlchemy's <strong>echo=True</strong> option prints every SQL query to the terminal as it is sent — essential for verifying that the ORM is generating the query you think it is. Wireshark can inspect raw HTTP and MySQL packets on the network, though this is rarely needed at Grade 9.

Understanding the stack also means understanding where security boundaries are. The browser is untrusted — any user can open DevTools and modify requests. Flask must validate all incoming data before trusting it. The database must never be exposed directly to the browser — only Flask, running on the server, should have database credentials. This is why the architecture is layered: each layer is a checkpoint that validates and transforms data before passing it on.