Database query dominates processing time. Template rendering adds 30ms overhead for HTML generation.
Template Performance Considerations
Template rendering cost depends on complexity:
Fast operations:
Variable substitution: { value }
Simple loops: 100 items ~ 10ms
Conditionals: {% if %} ~ negligible
Built-in filters: round, upper ~ negligible
Slower operations:
Large loops: 10,000 items ~ 500ms
Nested loops: O(n²) complexity
Complex computations in template
Custom filters with heavy processing
Optimization strategies:
Compute in Python, not template:
# Good: compute before rendertotal =sum(x.size for x in docs)render_template('page.html', total=total)# Bad: compute in template# {% set total = 0 %}# {% for doc in docs %}...{% endset %}
Limit loop iterations: Paginate large lists. Show 50 items per page, not 10,000.
Cache rendered templates: For pages with same data shown to many users (product catalog).
Different Data, Same Template
Single template generates different output for each user:
Partial _document_card.html reused for each document. Document display logic centralized.
Combined: Inheritance and Includes
Real applications combine both patterns:
templates/
base.html # Page structure (nav, footer)
_document_card.html # Reusable component
documents.html # Extends base, includes card
search.html # Extends base, includes card
upload.html # Extends base
documents.html:
{% extends "base.html" %}{% block content %}<h1>Documents</h1> {% for doc in documents %} {% include "_document_card.html" %} {% endfor %}{% endblock %}
search.html:
{% extends "base.html" %}{% block content %}<h1>Search Results</h1> {% for doc in results %} {% include "_document_card.html" %} {% endfor %}{% endblock %}
Both pages share base layout and document display component.
Templates Render User-Specific Content
Routes use session to identify current user, retrieve their data, pass to template.
@app.route('/documents')def view_documents(): user_id = session.get('user_id')ifnot user_id:return redirect('/login')# Query documents for this user docs = db.execute("SELECT * FROM documents WHERE owner_id = ?", user_id ).fetchall()return render_template('documents.html', documents=docs, username=session.get('username'))
Template receives user-specific data:
<h1>{{ username }}'s Documents</h1>{% for doc in documents %}<div>{{ doc.title }}</div>{% endfor %}
Same template generates different HTML for each user. Route reads session to determine current user, fetches their data, template renders personalized page.
Form Processing
Server Receives Form Submissions
Browser sends form data in HTTP request. Server must extract, validate, and process this data.
Every input validated. Malicious data rejected with 400 status.
Always validate every input on server. Client validation improves user experience. Server validation provides security.
Business Logic Validation
Validation beyond format checks:
Each check queries database or checks application state. Returns specific error with appropriate HTTP status (400 for validation, 403 for authorization).
{% if errors %}<div class="errors"> {% for error in errors %}<p>{{ error }}</p> {% endfor %}</div>{% endif %}<form method="POST"><input type="text" name="title" value="{{ title | default('') }}"><button>Submit</button></form>
Rendered output with validation errors:
Title required
Description too long
Form preserves user input. User corrects errors without re-typing valid fields.
Sessions and Cookies
HTTP Cannot Identify Users Across Requests
Server processes form submission successfully. User navigates to documents page. Server cannot determine which user made request.
Login succeeds:
POST /login HTTP/1.1Host: app.example.comusername=alice&password=...
HTTP/1.1 302 FoundLocation: /documents
Server validates credentials, redirects to documents.
Immediately after, request documents:
GET /documents HTTP/1.1Host: app.example.com
Server receives request. No indication which user. No connection to previous login request.
@app.route('/documents')def documents():# Which user is this? user_id = ???
Server must retrieve user-specific documents but cannot identify requester.
Every HTTP request independent. Previous authentication irrelevant.
Cookies Provide Request Identity
Server includes Set-Cookie header in HTTP response. Browser stores value. Browser automatically includes Cookie header in subsequent requests to same domain.
from flask import request@app.route('/documents')def documents(): user_id = request.cookies.get('user_id')ifnot user_id:return"Not authenticated", 401returnf"Documents for user {user_id}"
request.cookies reads Cookie header from request. Browser automatically includes cookie.
Browser stores when Set-Cookie header received. Storage occurs after response processed, before next request.
How long does cookie persist?
Without Max-Age or Expires: Session cookie, deleted when browser closed.
With Max-Age=604800: Persistent cookie, survives browser restart, expires after 604,800 seconds (7 days).
Set-Cookie: user_id=42; Max-Age=604800
Which requests include cookie?
Domain scope: - Cookie set by app.example.com sent to app.example.com - Not sent to other.com - Not sent to subdomain.app.example.com (unless Domain attribute set)
Path scope:
Set-Cookie: user_id=42; Path=/documents
Sent to /documents and /documents/view
Not sent to /search or /upload
Default: Path=/ (all paths on domain)
Browser decides which requests include cookie based on domain and path matching.
Cookie Access and Visibility
Who can read cookie value?
1. Server (always): Receives Cookie header with every request. Server-side code reads via request.cookies.
2. Browser JavaScript (by default):
document.cookie// Returns: "user_id=42"
Client-side code can read and modify cookie. User opens DevTools, views/edits cookies.
3. Network observers (if HTTP): Cookie transmitted in plaintext over HTTP. Anyone monitoring network sees cookie value.
Security implications:
Storing user_id=42 in cookie means: - User sees their own user ID - JavaScript on page reads user ID - User can modify: change user_id=42 to user_id=99 - Network sniffing reveals user ID
Modified cookie attack:
GET /documents HTTP/1.1Cookie: user_id=99
User changed cookie from 42 to 99. Server trusts cookie, returns user 99’s documents. Alice accesses Bob’s data.
Cookie contents visible and modifiable by client. Server cannot trust cookie data directly.
Session Pattern: Random ID Maps to Server Data
Store only unpredictable session ID in cookie. Store actual user data on server, indexed by session ID.
Login creates session:
import secrets@app.route('/login', methods=['POST'])def login(): username = request.form['username']# Validate credentials...# Generate random session ID session_id = secrets.token_hex(16)# Result: 'a7f3c9d1b2e4...' (32 chars)# Store on server sessions[session_id] = {'user_id': 42,'username': 'alice' }# Send ID to client response = make_response("Logged in") response.set_cookie('session_id', session_id)return response
Protected route uses session:
@app.route('/documents')def documents():# Read session ID from cookie session_id = request.cookies.get('session_id')# Look up server-side data session_data = sessions.get(session_id)ifnot session_data:return"Not authenticated", 401 user_id = session_data['user_id'] docs = get_user_documents(user_id)return render_template('docs.html', documents=docs)
Cookie contains: a7f3c9d1b2e4... Server contains: {user_id: 42, username: 'alice'}
Why Session Pattern Prevents Attacks
User modifies session ID:
Original cookie: session_id=a7f3c9d1b2e4
User changes to: session_id=modified_value
session_data = sessions.get('modified_value')# Returns None (not in server storage)ifnot session_data:return"Not authenticated", 401
Modified ID not in server’s session storage. Lookup fails, authentication rejected.
User guesses session ID:
Session ID is 128-bit random value:
secrets.token_hex(16) # 32 hex chars = 128 bits
2^128 possible values = 3.4 × 10^38 possible IDs.
Even trying 1 billion IDs per second: - Years required: 10^22 years - Age of universe: 1.4 × 10^10 years
Computationally infeasible to guess valid session ID.
Server invalidates immediately:
del sessions[session_id]
Even with original valid cookie, lookup fails. Logout takes effect instantly.
Cookies vs Sessions: When to Use Each
Sessions for authentication and sensitive data. Cookies for user preferences.
Data visible but cannot modify without invalidating signature.
Tradeoffs:
Advantages: - No server storage required - Works with multiple application servers (stateless) - No database/Redis dependency
Disadvantages: - 4KB cookie size limit - Data visible to user (base64 ≠ encryption) - Cannot invalidate specific session (no server record) - Session persists until cookie expires (logout clears cookie but data remains valid)
Suitable for: Small non-sensitive data (preferences, language). Not suitable for authorization data.
Session Storage: Redis (Production Pattern)
Cookie contains only session ID. Session data stored in Redis key-value store.
Store session in Redis:
import redisimport jsonimport secretsredis_client = redis.Redis( host='localhost', port=6379)@app.route('/login', methods=['POST'])def login(): username = request.form['username'] user_id =42# From database# Generate session ID session_id = secrets.token_hex(16)# Store in Redis with 1 hour expiration redis_client.setex(f'session:{session_id}',3600, # TTL in seconds json.dumps({'user_id': user_id,'username': username }) ) response = make_response(redirect('/documents')) response.set_cookie('session_id', session_id)return response
Retrieve session from Redis:
@app.route('/documents')def documents(): session_id = request.cookies.get('session_id')# Look up in Redis data = redis_client.get(f'session:{session_id}')ifnot data:return redirect('/login') session_data = json.loads(data) user_id = session_data['user_id'] docs = get_user_documents(user_id)return render_template('docs.html', documents=docs)
Performance: 1-2ms network round-trip to Redis. In-memory storage, very fast. Automatic expiration via TTL.
document field contains string "report.pdf", not file contents. Text encoding cannot represent 524KB of binary PDF data. File remains on client machine.
URL encoding designed for text - escapes =, &, spaces. No mechanism for transmitting binary streams.
Multipart Encoding Intermixes Binary and Text
Special content type allows single HTTP request to contain both text fields and binary file data.
User interaction: Click file input, select file from filesystem, click submit button.
Browser automation: Reads selected file into memory (524KB), generates random boundary string, constructs HTTP request with headers and body.
Network transmission: Entire request (537KB including headers and boundaries) sent to server.
Server receives: Flask parses multipart structure, provides file object with metadata (filename, content_type) and binary data (read() method).
Flask Parses Multipart Into File Objects
Server receives multipart request. Flask extracts boundaries, separates parts, provides file object with metadata and binary data accessible through methods.
@app.route('/upload', methods=['POST'])def upload():# Text field (standard form data) title = request.form['title']# Returns: "Q4 Report"# File object (from multipart data)file= request.files['document']# File metadata (from HTTP headers) filename =file.filename# Returns: "report.pdf" mimetype =file.content_type# Returns: "application/pdf"# Read file data into memory data =file.read()# Returns: b'%PDF-1.4...' (524,288 bytes) size =len(data)# Returns: 524288returnf"Uploaded {filename}: {size} bytes"
File object provides save() method for writing to filesystem. Original filenames cause overwrites and security issues.
@app.route('/upload', methods=['POST'])def upload():file= request.files['document']# Save with original filenamefile.save(f'/uploads/{file.filename}')return"Upload successful"
Timeline with multiple users:
10:00 AM: Alice uploads report.pdf → Saved to /uploads/report.pdf
10:15 AM: Bob uploads report.pdf → Overwrites /uploads/report.pdf
Alice’s file lost
Additional problems:
User uploads filename: ../../../etc/passwd
Path becomes: /uploads/../../../etc/passwd → Resolves to /etc/passwd
Overwrites system file.
import uuid@app.route('/upload', methods=['POST'])def upload():file= request.files['document']# Extract extension ext =file.filename.rsplit('.', 1)[1].lower()# "report.pdf" → "pdf"# Generate unique storage name storage_name =f"{uuid.uuid4()}.{ext}"# "7f3c9d1b-2e4a-4f5a-8c3d-9e2f1b4a6d8c.pdf"# Save with unique namefile.save(f'/uploads/{storage_name}')return storage_name
Timeline with UUID:
10:00 AM: Alice uploads report.pdf → 7f3c9d1b.pdf
10:15 AM: Bob uploads report.pdf → a9e2f3b4.pdf
Both files preserved
UUID contains only [a-f0-9-]. No path traversal possible. Collision probability: 2^-122 ≈ 0.
Database Maps Storage Names to Display Names
Filesystem stores UUID names. Database preserves original filenames for user display.
import sqlite3import uuidfrom datetime import datetime# Create databaseconn = sqlite3.connect(':memory:')conn.execute(''' CREATE TABLE files ( id INTEGER PRIMARY KEY, storage_name TEXT UNIQUE, original_name TEXT, size INTEGER, user_id INTEGER )''')# Simulate Alice uploading report.pdfalice_storage =f"{uuid.uuid4()}.pdf"conn.execute("INSERT INTO files (storage_name, original_name, size, user_id) VALUES (?, ?, ?, ?)", (alice_storage, "report.pdf", 524288, 1))# Simulate Bob uploading report.pdf (same name, different file)bob_storage =f"{uuid.uuid4()}.pdf"conn.execute("INSERT INTO files (storage_name, original_name, size, user_id) VALUES (?, ?, ?, ?)", (bob_storage, "report.pdf", 612352, 2))# Alice uploads another filealice_budget =f"{uuid.uuid4()}.xlsx"conn.execute("INSERT INTO files (storage_name, original_name, size, user_id) VALUES (?, ?, ?, ?)", (alice_budget, "budget.xlsx", 102400, 1))# Display Alice's files (what she sees)print("Alice's Files:")for row in conn.execute("SELECT original_name, size FROM files WHERE user_id = 1"):print(f" • {row[0]} ({row[1]:,} bytes)")print("\nActual storage names:")for row in conn.execute("SELECT original_name, storage_name FROM files WHERE user_id = 1"):print(f" {row[0]} → {row[1]}")
Problem: Browser doesn’t distinguish server-generated HTML from user-provided HTML. <script> tag in user input becomes executable code.
Demonstration: XSS Attack
from flask import Flask, render_template_stringfrom jinja2 import Template, Environmentapp = Flask(__name__)# Simulated database datadocuments = [ {'title': 'Q4 Report', 'author': 'Alice'}, {'title': '<script>alert("XSS")</script>', 'author': 'Attacker'}, {'title': 'Analysis', 'author': 'Bob'}]# WITHOUT auto-escaping (vulnerable)template_vulnerable ="""<ul>{% for doc in documents %} <li>{{ doc.title }} by {{ doc.author }}</li>{% endfor %}</ul>"""env_vulnerable = Environment(autoescape=False)result_vulnerable = env_vulnerable.from_string(template_vulnerable).render(documents=documents)print("WITHOUT auto-escaping (vulnerable):")print(result_vulnerable)print()# WITH auto-escaping (safe)template_safe = template_vulnerable # Same templateenv_safe = Environment(autoescape=True)result_safe = env_safe.from_string(template_safe).render(documents=documents)print("WITH auto-escaping (safe):")print(result_safe)
WITHOUT auto-escaping (vulnerable):
<ul>
<li>Q4 Report by Alice</li>
<li><script>alert("XSS")</script> by Attacker</li>
<li>Analysis by Bob</li>
</ul>
WITH auto-escaping (safe):
<ul>
<li>Q4 Report by Alice</li>
<li><script>alert("XSS")</script> by Attacker</li>
<li>Analysis by Bob</li>
</ul>
Vulnerable version: <script> appears in HTML output. Browser would execute.
Safe version: <script> displayed as text. Browser shows tag visually, doesn’t execute.
XSS Attack Chain
Vulnerability: Server stores user input. Template renders without escaping. Browser executes <script> tags. JavaScript runs with victim’s privileges.
Impact: Attacker’s code accesses victim’s session, reads sensitive data, makes authenticated requests, sends data to attacker-controlled server.
Jinja2 Auto-Escaping Converts HTML to Text
Flask templates escape HTML special characters by default. Prevents browser from interpreting user input as HTML structure.
Escape conversions:
Character
Escaped To
Meaning
<
<
Less than
>
>
Greater than
&
&
Ampersand
"
"
Double quote
'
'
Single quote
Browser sees < in HTML source, displays < character visually. Doesn’t create tag structure.
| safe filter marks content as trusted HTML. Use only for server-generated HTML, never user input.
Dangerous: Safe filter on user input
@app.route('/profile/<username>')def profile(username): user = get_user(username)# User controls bio fieldreturn render_template('profile.html', bio=user.bio)
Browser displays: <img src=x onerror="..."> as text.
No code execution.
Rule: Only use | safe on HTML you generate server-side. Never on user-submitted content (document titles, comments, bios, any form input).
Forms Accept Requests From Any Origin
Form processing (Part 3): user fills form, clicks submit, server processes. Server doesn’t verify which website created the form.
Your application’s form:
<!-- Served from app.example.com/settings --><form action="/settings/change-email" method="POST"><input name="email" placeholder="New email address"><button>Update Email</button></form>
Expected flow: User visits your site → Fills form → Clicks submit → Server processes.
Actual behavior: Any website can submit POST requests to your endpoints. Browser includes user’s authentication cookies automatically.
Malicious site creates form:
<!-- Served from evil.com --><form id="attack" action="https://app.example.com/settings/change-email" method="POST"><input type="hidden" name="email" value="attacker@evil.com"></form><script>document.getElementById('attack').submit();</script>
User visits evil.com while logged into app.example.com. Form auto-submits. Browser includes session cookie. Server sees authenticated request from Alice, changes her email to attacker’s address.
Alice never clicked anything. Page load triggered attack.
Why attacker fails:evil.com cannot read Alice’s session data (same-origin policy enforced by browser). Cannot include valid token in malicious form. Server rejects request without matching token.
Flask-WTF Automates CSRF Protection
Extension generates tokens, includes in forms, validates submissions automatically.
from flask import Flask, render_template_string, session, requestfrom flask_wtf import FlaskForm, CSRFProtectfrom wtforms import StringField, SubmitFieldimport secretsapp = Flask(__name__)app.secret_key = secrets.token_hex(16)# Enable CSRF protection globallycsrf = CSRFProtect(app)# Define form with fieldsclass SettingsForm(FlaskForm): email = StringField('Email Address') submit = SubmitField('Update')@app.route('/settings', methods=['GET', 'POST'])def settings(): form = SettingsForm()# validate_on_submit checks CSRF token automaticallyif form.validate_on_submit():# Token already validated by Flask-WTF new_email = form.email.dataprint(f"Email would be updated to: {new_email}")return"Email updated successfully"# Render formreturn render_template_string(""" <form method="POST">{{ form.hidden_tag() }}{{ form.email.label }}{{ form.email(size=30) }}{{ form.submit() }} </form> """, form=form)# Simulate legitimate requestwith app.test_client() as client:# GET form response = client.get('/settings')print("Form HTML includes hidden CSRF token field")print()# POST with token from form (works) response = client.post('/settings', data={'email': 'alice@example.com'}, follow_redirects=True)print("With valid token:", response.data.decode('utf-8'))
Form HTML includes hidden CSRF token field
With valid token: <!doctype html>
<html lang=en>
<title>400 Bad Request</title>
<h1>Bad Request</h1>
<p>The CSRF token is missing.</p>
form.hidden_tag() renders hidden input with CSRF token. form.validate_on_submit() verifies token automatically. POST requests without valid token rejected with 400 error.
Other Common Web Application Vulnerabilities
SQL Injection:
User input inserted directly into SQL queries. Attacker submits ' OR '1'='1 as username, query becomes SELECT * FROM users WHERE username='' OR '1'='1', returns all users.
Use parameterized queries
Path Traversal:
User controls filename in file operations. Attacker uploads file named ../../etc/passwd, application writes to system directories.
Sanitize filenames, validate paths stay within designated directories
Session Fixation:
Attacker provides session ID to victim. Victim logs in with attacker’s session ID. Attacker now shares authenticated session.
Regenerate session ID on login
Insecure Direct Object Reference:
URLs expose database IDs: /document/42. User changes URL to /document/43, accesses other user’s document.
Verify ownership before returning resources
Mass Assignment:
Form fields map directly to database columns. User adds is_admin=true to form submission, gains admin privileges.
Explicitly whitelist allowed fields
Information Disclosure:
Error messages reveal implementation details: PostgreSQL syntax error at line 42. Stack traces show file paths, library versions. Attacker learns system architecture.
Log detailed errors server-side, show generic messages to users
Client-Side Requests
Server Renders Complete HTML for Each Request
Standard approach: browser requests URL, server generates HTML, browser displays. Every interaction triggers new request and full page replacement.
User clicks “View Documents”:
GET /documents HTTP/1.1Cookie: session_id=abc123
Server executes route:
@app.route('/documents')def documents(): docs = db.execute("SELECT title, author FROM documents WHERE user_id = ?", [session['user_id']] ).fetchall()return render_template('documents.html', documents=docs)
Template generates complete HTML page. Browser replaces current page with response.
User clicks different document, process repeats. New request, new HTML, page replaced.
Page Replacement Discards Browser State
Browser discards current page completely when loading new URL. Scroll position, form input, expanded sections all lost.
Scenario: Lost scroll position
User scrolls through 50 documents to item 47. Clicks document to view. Clicks back button. Browser makes new request for /documents. Server renders fresh page. User returned to top of list.
Scenario: Lost form input
User fills search form with query. Before submitting, clicks link to view document. Returns to search page. Browser makes new request. Form empty.
Scenario: Multiple sequential views
User viewing document list. Clicks document 1, reads, clicks back. Clicks document 2, reads, clicks back. Each navigation: full page reload, scroll resets to top.
Browser navigation inherently stateless beyond what server stores in session.
JavaScript Executes on Loaded Page
JavaScript code runs within loaded page. Can respond to user actions, manipulate page content, make network requests.
from flask import Flask, render_template_stringapp = Flask(__name__)@app.route('/example')def example():return render_template_string(""" <html> <body> <h1>Document List</h1> <button id="load-btn">Load Documents</button> <ul id="doc-list"></ul> <script> document.getElementById('load-btn').addEventListener('click', function() { // JavaScript executes when button clicked console.log('Button clicked - JavaScript executing'); // Can manipulate page document.getElementById('doc-list').innerHTML = '<li>Loading...</li>'; // Can make network requests (shown in next slides) }); </script> </body> </html> """)with app.test_client() as client: response = client.get('/example')print("Server sends HTML with embedded JavaScript:")print(response.data.decode('utf-8')[:400] +'...')
Server sends HTML with embedded JavaScript:
<html>
<body>
<h1>Document List</h1>
<button id="load-btn">Load Documents</button>
<ul id="doc-list"></ul>
<script>
document.getElementById('load-btn').addEventListener('click', function() {
// JavaScript executes when button clicked
console.log('Button clicked - JavaScript executing');
...
Page loads once. JavaScript remains active, can respond to clicks, form input, timers. Does not require page reload to execute.
JavaScript Sends HTTP Requests Without Navigation
Browser provides fetch() API for JavaScript to make HTTP requests. Page remains loaded while request executes.
Browser navigation:
User clicks link → Browser sends HTTP request → Browser waits → Response arrives → Browser discards current page → Browser loads new page.
JavaScript fetch:
User clicks button → JavaScript calls fetch('/api/documents') → Browser sends HTTP request in background → Page remains visible and interactive → Response arrives → JavaScript receives data → JavaScript can update page.
Two mechanisms for HTTP requests. Browser navigation replaces page. JavaScript fetch operates within loaded page.
Server Returns JSON Instead of Rendered HTML
Route can return data in JSON format rather than rendered template. Same database query, different response format.
Template-rendering route:
@app.route('/documents')def documents(): docs = db.execute(""" SELECT title, author, date FROM documents WHERE user_id = ? """, [session['user_id']]).fetchall()return render_template('documents.html', documents=docs)
Template generates HTML structure:
<ul><li>Q4 Report by Alice</li><li>Analysis by Bob</li></ul>
Browser receives complete HTML ready to display.
JSON-returning route:
@app.route('/api/documents')def api_documents(): docs = db.execute(""" SELECT title, author, date FROM documents WHERE user_id = ? """, [session['user_id']]).fetchall()return jsonify([ {'title': d['title'],'author': d['author'],'date': d['date']}for d in docs ])
JavaScript receives data, must build HTML structure.
Demonstration: Fetch Request and JSON Response
from flask import Flask, jsonifyapp = Flask(__name__)@app.route('/api/documents')def api_documents():# Simulated database query result docs = [ {'title': 'Q4 Report', 'author': 'Alice', 'date': '2024-10-15'}, {'title': 'Analysis', 'author': 'Bob', 'date': '2024-10-12'}, {'title': 'Summary', 'author': 'Charlie', 'date': '2024-10-10'} ]return jsonify(docs)with app.test_client() as client: response = client.get('/api/documents')print("HTTP Response:")print(f" Status: {response.status_code}")print(f" Content-Type: {response.content_type}")print() data = response.get_json()print("Parsed JSON data (available to JavaScript):")print(f" Type: {type(data)}")print(f" Length: {len(data)}")print()print("Accessing individual documents:")print(f" First title: {data[0]['title']}")print(f" Second author: {data[1]['author']}")print()print("Iterating through documents:")for doc in data:print(f" - {doc['title']} by {doc['author']}")
HTTP Response:
Status: 200
Content-Type: application/json
Parsed JSON data (available to JavaScript):
Type: <class 'list'>
Length: 3
Accessing individual documents:
First title: Q4 Report
Second author: Bob
Iterating through documents:
- Q4 Report by Alice
- Analysis by Bob
- Summary by Charlie
JavaScript receives array of objects. Can access properties, loop through items, use data to build page content.
JavaScript Builds DOM Elements from Data
JavaScript creates HTML elements programmatically, inserts into page. Template generates HTML on server; JavaScript generates HTML in browser.
Page loads with empty list. JavaScript fetches data, creates <li> elements, appends to list.
Result same as server-rendered template: list of documents. Difference: HTML generated in browser rather than on server.
Comparing HTML Generation Locations
Both approaches query database, generate HTML list, display to user. Location of HTML generation differs.
Form Submission Without Page Reload
JavaScript can intercept form submission, send request with fetch, handle response without navigation.
Traditional form submission:
User fills form, clicks submit. Browser sends POST request, waits for response, replaces page with response HTML. Validation error returns form with error message. User input preserved via template rendering submitted values.
Form input remains in fields. Error appears without page reload. User corrects title, resubmits. Description not lost.
Server Endpoint Structure for JSON Response
from flask import Flask, request, jsonifyapp = Flask(__name__)@app.route('/api/create', methods=['POST'])def api_create(): data = request.get_json() title = data.get('title', '').strip()# Validationifnot title:return jsonify({'error': 'Title required'}), 400iflen(title) <3:return jsonify({'error': 'Title must be at least 3 characters'}), 400# Would save to database doc_id =123# Simulatedreturn jsonify({'success': True, 'id': doc_id})with app.test_client() as client:# Test invalid response = client.post('/api/create', json={'title': 'Re'}, content_type='application/json')print("Short title:")print(f" Status: {response.status_code}")print(f" Response: {response.get_json()}")print()# Test valid response = client.post('/api/create', json={'title': 'Q4 Report'}, content_type='application/json')print("Valid title:")print(f" Status: {response.status_code}")print(f" Response: {response.get_json()}")
Short title:
Status: 400
Response: {'error': 'Title must be at least 3 characters'}
Valid title:
Status: 200
Response: {'id': 123, 'success': True}
Same validation logic as template-rendering route. Returns JSON instead of HTML. JavaScript receives response, decides how to update page.
Patterns in Modern Web Applications
Applications commonly use both server-rendered pages and JavaScript fetch requests.
Search autocomplete:
User types in search field. JavaScript sends request for each keystroke. Server returns matching results as JSON. JavaScript displays dropdown suggestions. No page reload.
Infinite scroll:
User scrolls to bottom of document list. JavaScript detects scroll position. Sends request for next page of results. Server returns JSON. JavaScript appends new items to list. User continues scrolling.
Live notifications:
JavaScript sends periodic requests to check for new notifications. Server returns count and recent items as JSON. JavaScript updates notification badge. No user action required.
Inline editing:
User clicks “Edit” button on document title. JavaScript shows text input with current value. User modifies, clicks “Save”. JavaScript sends updated value. Server validates, saves, returns success. JavaScript hides input, shows updated text. Document list not reloaded.
Page loads once with server-rendered HTML. Subsequent interactions use JavaScript fetch for partial updates. Combines fast initial load with smooth interactions.
