Belajar Flask - Arsitektur & Konsep Inti

#Pendahuluan

Setelah di episode 1 kita memahami sejarah dan filosofi Flask, pada episode ini kita membongkar cara kerjanya dari dalam. Mengapa ini penting? Karena hampir semua kebingungan saat memakai Flask — "kenapa g selalu error di sini?", "kenapa current_app dipakai di luar route?", "kenapa blueprint butuh url_prefix?" — bermuara pada belum pahamnya arsitektur ini. Kuasai arsitekturnya, dan debugging Flask terasa jauh lebih ringan.

Kita akan membahas empat pilar: lapisan WSGI, application factory pattern, dua macam context, serta hooks dan blueprints.

#Lapisan WSGI: Server Bertemu Aplikasi

Flask berdiri di atas WSGI (Web Server Gateway Interface) — kontrak Python standar yang menghubungkan web server (Gunicorn, uWSGI) dengan aplikasi. Konsepnya sederhana: aplikasi adalah callable yang menerima environ (dict berisi HTTP request) dan start_response, lalu mengembalikan iterable body.

WSGI callable paling dasar

def app(environ: dict, start_response: callable) -> list:
    status = "200 OK"
    headers = [("Content-Type", "text/plain")]
    start_response(status, headers)
    return [b"Hello WSGI"]

Flask (via Werkzeug) membungkus kerumitan ini. Kalian cukup menulis fungsi route, dan Werkzeug yang menerjemahkan environ menjadi objek request serta merangkai response menjadi WSGI-compatible. Itulah alasan aplikasi Flask bisa dijalankan oleh server WSGI apa pun — Gunicorn, uWSGI, bahkan waitress.

100%

Alur di atas: server menerima HTTP request, memanggil aplikasi Flask sebagai WSGI callable, Werkzeug mem-parsing request, Flask mencocokkan URL ke view function, lalu merender response (sering lewat Jinja2).

#Request Context vs Application Context

Dua konsep paling sering membingungkan: request context dan application context. Keduanya adalah tempat penyimpanan data sementara selama satu request/satu interaksi.

Membedakan current_app, g, dan request

from flask import current_app, g, request
 
 
@app.get("/")
def index() -> str:
    print(current_app.name)   # nama aplikasi -> dari application context
    print(request.path)       # path URL -> dari request context
    g.user = "devnull"        # g: data sementara selama request ini
    return f"Halo {g.user}"

request dan session hanya hidup selama request berlangsung. current_app dan g hidup selama application context — yang otomatis dibuka saat request masuk. Memahami ini menjelaskan kenapa current_app bisa diakses di helper yang dipanggil dari dalam route, tetapi error Working outside of application context jika dipanggil dari thread lain tanpa context.

#Application Factory Pattern

Daripada membuat aplikasi di modul level — yang membuat testing sulit dan konfigurasi kaku — Flask menganjurkan application factory: sebuah fungsi create_app() yang merangkai konfigurasi, extension, dan blueprint, lalu mengembalikan instance Flask.

app/__init__.py - application factory

from flask import Flask
 
 
def create_app() -> Flask:
    app = Flask(__name__)
    app.config.from_object("app.config.Config")
 
    from app.routes import main_bp
    app.register_blueprint(main_bp)
 
    return app

Keuntungannya: setiap instance aplikasi baru (misal satu untuk testing, satu untuk produksi) dengan konfigurasi berbeda tanpa memutasi state global. Kita bangun struktur proyek lengkap berbasis factory di episode 9.

#Blueprints: Memecah Aplikasi Menjadi Modul

Saat aplikasi membesar, satu file app.py akan sulit dikelola. Blueprint adalah cara Flask membagi aplikasi menjadi modul yang punya route, template, dan static files sendiri.

Blueprint auth sederhana

from flask import Blueprint, render_template
 
auth_bp = Blueprint("auth", __name__, url_prefix="/auth")
 
 
@auth_bp.route("/login")
def login():
    return render_template("auth/login.html")

Blueprint bukan aplikasi — ia adalah komponen yang menunggu diregistrasikan ke aplikasi lewat app.register_blueprint(auth_bp). url_prefix="/auth" membuat semua route di dalamnya otomatis berada di bawah /auth/.... Detail lengkap — template dan static per blueprint, nested blueprint — kita bahas di episode 9.

#Hooks: before/after_request

Flask menyediakan hooks untuk menyuntikkan logika sebelum atau sesudah request diproses — mirip middleware di framework lain:

• before_request: berjalan sebelum view dipanggil (misal cek login, buka koneksi DB).
• after_request: berjalan sesudah view selesai, menerima response (misal tambah header keamanan).
• teardown_request: berjalan di akhir apapun kondisinya, ideal untuk cleanup.

Hooks untuk timing dan header

from flask import g, request
 
 
@app.before_request
def load_user() -> None:
    g.user = get_user(request.headers.get("Authorization"))
 
 
@app.after_request
def add_security_headers(response):
    response.headers["X-Content-Type-Options"] = "nosniff"
    return response

Hooks ini penting karena memungkinkan logika lintas-request ditulis sekali di satu tempat, bukan disalin ke setiap view — praktik yang kembali kita pakai di episode 13 (auth) dan 17 (security headers).

#Common Pitfalls Arsitektur

Beberapa kesalahan umum yang sering ditemui pemula:

• Memakai g di luar request: g hanya hidup dalam application/request context. Simpan data dengan umur panjang ke database atau cache, bukan g.
• Blueprint tanpa url_prefix: semua route bertumpuk dan bisa bentrok. Prefix sejak awal.
• Mengakses current_app di module-level: saat import, belum ada application context. Akses di dalam fungsi, bukan di module level.
• Membuat banyak instance Flask di module level: gunakan factory agar instance terkontrol.

#Penutup

Pada episode 2 ini, kalian telah memahami arsitektur yang menopang semua kode Flask ke depan.

Inti yang harus dibawa pulang:

• Flask adalah WSGI app yang memakai Werkzeug sebagai toolkit dan Jinja2 untuk templating.
• Request context (request, session) vs application context (current_app, g).
• Application factory (create_app()) untuk konfigurasi dan testing yang rapi.
• Blueprint memecah aplikasi jadi modul; hooks before/after_request untuk logika lintas-request.

Di episode 3 selanjutnya kita masuk ke praktik nyata pertama: instalasi dan Hello World — menjalankan flask --app app run, memahami debug mode, environment variables, dan struktur minimal aplikasi Flask. Pastikan environment episode 0 sudah siap, karena mulai sekarang kalian menulis kode!