Integrasi Antarmuka GUI dengan Komponen Python dan Operasi CRUD

Pertemuan 11 — Lab Pemrograman · Bisnis Digital FEB UNDIP

RPS minggu 12 · 2x50 menit CRUD Python Backend GUI Integration

Selamat datang di Pertemuan 11, Anda sudah membangun database di Pertemuan 9 dan berlatih simulasi pertukaran data dengan dummy API di Pertemuan 10 — sekarang saatnya menyatukan keduanya secara nyata. Hari ini Anda akan belajar bagaimana antarmuka GUI, baik layar aplikasi React Native maupun jendela desktop Python, bisa berbicara langsung dengan komponen Python di belakang layar untuk melakukan empat operasi dasar data: Create, Read, Update, Delete, atau yang biasa disingkat CRUD. Bayangkan aplikasi pendataan UMKM seperti yang dipakai Dinas Koperasi Kota Semarang — setiap kali admin menambah usaha baru, mengubah alamat, atau menghapus data yang tidak valid, di balik tombol yang mereka klik ada kode Python yang bekerja mengelola data tersebut. Setelah pertemuan ini Anda akan mampu menulis dan menghubungkan keempat operasi itu dari nol.

Agenda Pertemuan

Sesi 1 — Konsep & Arsitektur (50 menit)

Recap singkat: database (P9) & dummy API (P10)
Konsep CRUD dan pemetaannya ke method HTTP
Arsitektur integrasi GUI ↔ Python ↔ Database
Mengapa Python cocok sebagai jembatan backend

Sesi 2 — Praktik CRUD (50 menit)

Menulis fungsi Create, Read, Update, Delete
Menghubungkan GUI ke endpoint CRUD
Validasi input & penanganan error
Latihan terpandu: studi kasus pendataan UMKM

Tujuan Pembelajaran

Tujuan 1

Menjelaskan konsep CRUD dan memetakan tiap operasi ke method HTTP yang sesuai (POST, GET, PUT/PATCH, DELETE).

Tujuan 2

Menulis komponen Python yang menjalankan operasi Create, Read, Update, dan Delete terhadap data.

Tujuan 3

Menghubungkan antarmuka GUI dengan komponen Python tersebut, lengkap dengan validasi dan penanganan error.

Sub-CPMK Minggu 12: mahasiswa mampu mengintegrasikan antarmuka GUI dengan komponen Python untuk menjalankan operasi CRUD secara utuh dan teruji.

Bagian 1 dari 3

Konsep CRUD & Arsitektur Integrasi

Dari database (P9) dan dummy API (P10) menuju komponen Python nyata yang menjalankan operasi data.

CRUD Arsitektur Python

Recap Kilat: Bekal dari Pertemuan Sebelumnya

Dua pertemuan terakhir membangun fondasi yang kita pakai hari ini secara langsung.

Pertemuan 9 — Database

Anda merancang tabel (misalnya mahasiswa, produk, umkm) dengan kolom dan tipe data yang jelas — inilah tempat data CRUD hari ini benar-benar tersimpan.

Pertemuan 10 — Dummy API

Anda mensimulasikan pertukaran data dengan endpoint palsu — hari ini endpoint itu kita ganti dengan komponen Python asli yang membaca & menulis ke database sungguhan.

Intinya: GUI tidak pernah menyentuh database secara langsung — selalu lewat komponen Python yang menjadi perantara resmi.

Apa Itu CRUD? Empat Operasi Dasar Data

Operasi	Method HTTP	Contoh Aksi di Aplikasi
Create — tambah data baru	`POST`	Mendaftarkan UMKM baru ke sistem
Read — baca / tampilkan data	`GET`	Menampilkan daftar produk di layar
Update — ubah data yang ada	`PUT` / `PATCH`	Mengoreksi alamat toko yang salah ketik
Delete — hapus data	`DELETE`	Menghapus akun pengguna yang tidak aktif

CRUD adalah singkatan yang mewakili hampir semua kebutuhan pengelolaan data dalam aplikasi bisnis digital — dari e-commerce sampai sistem akademik.

Arsitektur Integrasi: GUI ↔ Python ↔ Database

GUI hanya "meminta" — semua logika & keamanan CRUD hidup di komponen Python, bukan di layar aplikasi.

Diagram ini adalah peta jalan seluruh materi hari ini. Di sisi kiri ada antarmuka GUI — bisa layar aplikasi React Native seperti yang Anda bangun sejak Pertemuan 3, atau jendela desktop sederhana memakai Tkinter di Python sendiri. Di tengah ada komponen Python yang menjadi jembatan, tempat keempat fungsi CRUD hidup lengkap dengan validasi dan penanganan error. Di kanan ada database tempat data sesungguhnya tersimpan permanen, sesuai struktur yang Anda rancang di Pertemuan 9. Poin pentingnya: GUI tidak pernah "pintar" secara data — ia hanya mengirim permintaan dan menampilkan hasil, sementara semua aturan bisnis dan keamanan berada di komponen Python di tengah. Ini mirip pelayan restoran yang mencatat pesanan Anda tapi tidak memasak sendiri — dapur (Python dan database) yang mengerjakan semuanya.

Mengapa Python Cocok Menjadi Jembatan?

Kemudahan Sintaks

Kode singkat & mudah dibaca, cocok untuk pemula
Framework ringan: Flask untuk membuat endpoint CRUD dalam hitungan baris
Library GUI desktop bawaan: Tkinter

Ekosistem Data

Library database matang: sqlite3, SQLAlchemy
Mudah tersambung ke REST API (Pertemuan 8) yang dikonsumsi React Native
Dipakai luas industri Indonesia: fintech, marketplace, layanan pemerintah

Hari ini kita pakai Flask sebagai kerangka Python untuk menulis fungsi CRUD yang bisa dipanggil dari GUI mana pun.

Bagian 2 dari 3

Membangun Operasi CRUD Langkah demi Langkah

Create • Read • Update • Delete — kode Python nyata yang dijalankan dari GUI.

Create Read Update Delete

CREATE — Menambah Data Baru

@app.route("/umkm", methods=["POST"])
def create_umkm():
  data = request.get_json()
  # simpan ke tabel umkm di database
  db.execute("INSERT INTO umkm (nama, alamat) VALUES (?, ?)",
       (data["nama"], data["alamat"]))
  return {"status": "tersimpan"}, 201

1GUI mengirim data form (nama & alamat UMKM) via POST
2Python menerima data lewat request.get_json()
3Python menjalankan perintah INSERT INTO ke database
4Python mengembalikan status 201 (berhasil dibuat) ke GUI

Ini adalah operasi Create pertama kita — menambahkan data UMKM baru ke sistem. Perhatikan alurnya: GUI mengirim data dalam format yang sudah Anda kenal dari REST API di Pertemuan 8, Python menangkapnya dengan request.get_json(), lalu menjalankan perintah SQL INSERT INTO untuk menyimpannya ke tabel yang Anda rancang di Pertemuan 9. Angka 201 yang dikembalikan bukan angka sembarangan — itu kode status HTTP standar yang berarti "resource berhasil dibuat", berbeda dari 200 yang berarti "berhasil" secara umum. Bayangkan admin Dinas Koperasi mengisi formulir pendaftaran UMKM baru di layar aplikasi — begitu tombol "Simpan" ditekan, alur inilah yang berjalan di belakang layar dalam hitungan mili-detik.

READ — Membaca & Menampilkan Data

@app.route("/umkm", methods=["GET"])
def read_umkm():
  page = request.args.get("page", 1, type=int)
  limit = 20
  offset = (page - 1) * limit
  rows = db.execute("SELECT * FROM umkm LIMIT ? OFFSET ?",
       (limit, offset))
  return jsonify(rows)

Mengapa perlu OFFSET? Karena menampilkan ribuan data UMKM sekaligus akan membuat GUI lambat — data dipecah per halaman (paginasi).

Langkah	Perhitungan	Nilai
Halaman yang diminta GUI	page = 3	3
Jumlah data per halaman	limit = 20	20
Hitung offset	(page − 1) x limit = (3−1) x 20	40
Query yang dijalankan Python	`LIMIT 20 OFFSET 40`	baris ke-41–60

Read terlihat sederhana — tinggal ambil semua data — tetapi dalam praktik nyata kita hampir tidak pernah mengambil seluruh data sekaligus, karena aplikasi seperti direktori UMKM se-Jawa Tengah bisa punya puluhan ribu baris. Di sinilah konsep paginasi berperan: kita hitung offset, yaitu berapa banyak baris yang perlu dilompati sebelum mulai menampilkan halaman yang diminta. Mari kita hitung bersama: jika pengguna membuka halaman ketiga dengan dua puluh data per halaman, maka offset adalah dua dikali dua puluh sama dengan empat puluh baris dilompati, sehingga Python mengambil baris ke-41 sampai ke-60. Rumus (page − 1) × limit ini akan terus Anda pakai setiap kali membangun fitur daftar data dengan tombol "halaman berikutnya" di aplikasi mana pun.

UPDATE — Mengubah Data yang Sudah Ada

@app.route("/umkm/<id>", methods=["PUT"])
def update_umkm(id):
  data = request.get_json()
  db.execute("UPDATE umkm SET alamat = ? WHERE id = ?",
       (data["alamat"], id))
  return {"status": "terbarui"}, 200

1GUI mengirim id UMKM yang mau diubah + data baru, via PUT
2Python mencocokkan WHERE id = ? agar hanya baris itu yang berubah
3Python menjalankan UPDATE ... SET ke database
4Python mengembalikan status 200 (berhasil) ke GUI, layar menampilkan data terbaru

Tanpa klausa WHERE id = ? yang tepat, SEMUA baris ikut berubah — kesalahan paling sering terjadi pada Update.

Update mirip Create, tetapi ada satu perbedaan krusial: kita harus memberi tahu database baris mana yang mau diubah, memakai klausa WHERE. Perhatikan kode ini menerima id lewat URL, misalnya /umkm/17 untuk mengubah UMKM dengan id tujuh belas, lalu klausa WHERE id = ? memastikan hanya baris itu yang tersentuh. Peringatan yang saya beri di kotak bawah bukan basa-basi — ini kesalahan paling umum yang dilakukan pemrogram pemula: lupa menulis WHERE sehingga perintah UPDATE mengubah seluruh baris di tabel sekaligus. Contohnya, kalau admin ingin mengoreksi alamat satu UMKM tapi klausa WHERE-nya salah, bisa saja alamat seluruh UMKM di database ikut tertimpa dengan alamat yang sama — kesalahan yang sangat merepotkan untuk diperbaiki.

DELETE — Menghapus Data

@app.route("/umkm/<id>", methods=["DELETE"])
def delete_umkm(id):
db.execute("DELETE FROM umkm WHERE id = ?", (id,))
return {"status": "terhapus"}, 200

Mari lacak jumlah data UMKM aktif melalui satu siklus CRUD berurutan hari ini:

Langkah	Perhitungan	Nilai
Data awal (hasil READ pagi ini)	50 UMKM terdaftar	50
CREATE: 8 UMKM baru mendaftar	50 + 8	58
UPDATE: 3 UMKM koreksi alamat	58 (jumlah tetap)	58
DELETE: 6 UMKM tidak aktif dihapus	58 − 6	52

Delete adalah operasi paling singkat kodenya tetapi paling berisiko akibatnya, karena data yang terhapus umumnya tidak bisa dikembalikan begitu saja — sama seperti Update, ia wajib memakai WHERE id = ? agar hanya baris yang dimaksud yang hilang. Sekarang mari kita telusuri bagaimana jumlah data bergerak melalui satu hari kerja penuh operasi CRUD: kita mulai dengan lima puluh UMKM terdaftar hasil Read pagi ini, lalu delapan UMKM baru mendaftar lewat Create sehingga menjadi lima puluh delapan, tiga di antaranya melakukan Update alamat sehingga jumlah tidak berubah, dan terakhir enam UMKM yang sudah tutup dihapus lewat Delete sehingga tersisa lima puluh dua. Latihan berhitung sederhana ini penting supaya Anda terbiasa memverifikasi: setelah serangkaian operasi CRUD, apakah jumlah data di database sudah sesuai yang Anda harapkan, sebuah kebiasaan debugging yang akan sangat berguna di Pertemuan 13.

Coba Sendiri: Simulasikan DELETE dan ON DELETE CASCADE

Hapus satu baris induk lalu amati apakah baris anak terkait ikut terhapus (CASCADE) atau justru ditolak database.

Menghubungkan GUI ke Endpoint CRUD

React Native (mobile)

fetch("http://server/umkm", {
method: "POST",
body: JSON.stringify(formData)
})

Tkinter (desktop)

def on_simpan_klik():
requests.post("http://server/umkm",
json=form_data)

Baik fetch() di React Native maupun requests.post() di Tkinter, keduanya memanggil endpoint Flask yang sama — satu backend Python melayani dua jenis GUI sekaligus.

Ini adalah momen "aha" yang saya harap Anda rasakan hari ini: komponen Python CRUD yang sama bisa dipanggil dari dua jenis antarmuka yang sangat berbeda. Di sisi kiri, aplikasi React Native memakai fungsi fetch() yang sudah Anda pelajari sejak Pertemuan 4 dan 8 untuk mengirim data form ke server. Di sisi kanan, aplikasi desktop Tkinter memakai library requests untuk melakukan hal yang persis sama, hanya beda bahasa pemanggilan. Karena keduanya berbicara lewat REST API yang formatnya standar, backend Flask tidak peduli apakah permintaan datang dari ponsel Android seorang pedagang UMKM atau dari komputer desktop admin di kantor Dinas Koperasi — selama formatnya benar, endpoint yang sama bisa melayani semuanya. Inilah kekuatan sesungguhnya dari memisahkan GUI dan komponen Python: satu backend, banyak antarmuka.

Validasi Input & Penanganan Error

@app.route("/umkm", methods=["POST"])
def create_umkm():
  data = request.get_json()
  if not data.get("nama"):
    return {"error": "nama wajib diisi"}, 400
  try:
    db.execute("INSERT INTO umkm ...", ...)
  except Exception as e:
    return {"error": str(e)}, 500

200 / 201

Berhasil

400

Input tidak valid (kesalahan GUI/pengguna)

500

Error di server Python (bukan salah pengguna)

Kode yang sudah kita bangun sejauh ini masih "polos" — ia mengasumsikan data yang dikirim GUI selalu benar, padahal di dunia nyata pengguna bisa lupa mengisi nama UMKM atau koneksi internet bisa terputus di tengah proses. Validasi seperti if not data.get("nama") ini mencegah data kosong tersimpan ke database, dan blok try except menangkap error tak terduga seperti koneksi database yang gagal, supaya aplikasi tidak crash tiba-tiba. Perhatikan tiga kelompok kode status di bawah: dua ratus atau dua ratus satu berarti berhasil, empat ratus berarti kesalahan ada di sisi pengguna atau GUI seperti input kosong, sementara lima ratus berarti masalah ada di server Python itu sendiri. Membedakan ketiganya penting agar GUI bisa menampilkan pesan yang tepat — pengguna UMKM yang lupa isi nama toko perlu pesan berbeda dari pengguna yang mengalami gangguan server.

Bagian 3 dari 3

Praktik & Studi Kasus

Menyatukan Create, Read, Update, Delete dalam satu alur aplikasi pendataan UMKM.

Studi Kasus Debugging Latihan

Studi Kasus: Aplikasi Pendataan UMKM End-to-End

1Admin membuka aplikasi → GUI memanggil GET /umkm → layar menampilkan daftar UMKM (Read)
2Admin menekan "Tambah UMKM" → isi form → GUI memanggil POST /umkm (Create)
3Admin menyadari alamat salah ketik → edit → GUI memanggil PUT /umkm/17 (Update)
4UMKM tersebut tutup permanen → admin menekan "Hapus" → GUI memanggil DELETE /umkm/17 (Delete)
5Layar otomatis memanggil ulang GET /umkm → daftar ter-update tanpa admin refresh manual

Kesalahan Umum Integrasi GUI ↔ Python

Gejala	Penyebab Umum
Semua data ikut berubah/terhapus	Lupa klausa `WHERE id = ?` pada Update/Delete
GUI menampilkan layar kosong	Format JSON respons Python tidak cocok dengan yang diharapkan GUI
Error 500 tanpa pesan jelas	Tidak ada blok `try except` untuk menangkap error database
Data lama masih tampil setelah Create	GUI tidak memanggil ulang Read setelah operasi berhasil

Kebiasaan baik: uji setiap endpoint CRUD satu per satu (via Postman/browser) sebelum menghubungkannya ke GUI.

Tabel ini adalah rangkuman kesalahan yang paling sering saya temui saat mendampingi mahasiswa praktik integrasi GUI dengan Python. Kesalahan klausa WHERE sudah kita bahas di slide Update, tetapi dua baris berikutnya juga sering menjebak pemula: ketidakcocokan format data antara yang dikirim Python dan yang diharapkan GUI, serta lupa menangani error sehingga aplikasi menampilkan pesan yang membingungkan pengguna. Saran praktis yang sangat saya rekomendasikan: sebelum menyambungkan endpoint ke GUI, uji dulu endpoint itu secara terpisah, misalnya lewat browser untuk method GET atau lewat aplikasi seperti Postman untuk method lain. Kebiasaan menguji backend secara terisolasi ini akan sangat menghemat waktu debugging Anda di Pertemuan 13 saat evaluasi proyek akhir.

Latihan Praktik Terpandu

Tugas hari ini: lengkapi keempat fungsi CRUD (create, read, update, delete) pada proyek database Pertemuan 9 milik kelompok Anda, lalu hubungkan ke GUI aplikasi yang sedang dibangun.

Langkah Kerja

Buka proyek Flask & database dari Pertemuan 9
Tulis 4 endpoint CRUD sesuai pola hari ini
Uji tiap endpoint lewat browser/Postman
Hubungkan ke tombol/form di GUI aplikasi kelompok

Kriteria Selesai

Create menyimpan data baru ke database
Read menampilkan data (dengan paginasi)
Update & Delete hanya menyentuh baris yang dimaksud
Ada validasi input & penanganan error minimal

Waktu praktik: sisa sesi 2. Dampingan dosen & asisten tersedia — bertanya kapan pun menemui kebuntuan.

Sekarang giliran Anda praktik langsung, dan slide ini sengaja tidak beranimasi bertahap karena semua instruksi perlu Anda lihat sekaligus sebagai acuan kerja kelompok. Kembalilah ke proyek database dan Flask yang sudah Anda mulai di Pertemuan 9, lalu lengkapi keempat fungsi CRUD mengikuti pola yang sudah kita bahas — Create untuk menambah, Read untuk menampilkan lengkap dengan paginasi, Update dan Delete yang wajib memakai klausa WHERE yang tepat. Jangan langsung menghubungkan ke GUI sebelum menguji tiap endpoint secara terpisah, sesuai kebiasaan baik yang baru kita bahas. Saya dan asisten akan berkeliling selama sisa sesi ini, jadi jangan ragu memanggil kami begitu Anda menemui error yang membingungkan, terutama seputar format JSON atau koneksi database.

Ringkasan & Jembatan ke Pertemuan 12

Yang Sudah Anda Kuasai

Konsep CRUD & pemetaannya ke method HTTP
Arsitektur GUI ↔ Python ↔ Database
Menulis keempat fungsi CRUD di Flask
Menghubungkan GUI (React Native & Tkinter) ke endpoint CRUD
Validasi input & penanganan error dasar

Pertemuan 12 Mendatang

Integrasi komponen front-end & back-end dalam satu sistem aplikasi utuh
Menyatukan seluruh potongan (UI, state, navigasi, API, database, CRUD) dari P1–P11
Persiapan menuju evaluasi & debugging proyek akhir (P13–P14)

Mari kita rangkum perjalanan hari ini: Anda sudah memahami konsep CRUD dan pemetaannya ke method HTTP, melihat bagaimana GUI, Python, dan database saling berbicara, menulis keempat fungsi CRUD dari nol memakai Flask, serta menghubungkannya ke dua jenis antarmuka berbeda lengkap dengan validasi dasar. Semua kemampuan ini adalah potongan puzzle terakhir yang Anda butuhkan sebelum Pertemuan 12, saat kita akan menyatukan front-end dan back-end menjadi satu sistem aplikasi yang benar-benar utuh — menggabungkan UI dari Pertemuan 2 dan 3, state serta navigasi dari Pertemuan 5 dan 7, REST API dari Pertemuan 8, database dari Pertemuan 9, hingga CRUD hari ini. Pastikan proyek CRUD kelompok Anda sudah berjalan stabil sebelum pertemuan berikutnya, karena kita akan langsung membangunnya menjadi aplikasi utuh tanpa mengulang dasar-dasarnya lagi. Sampai jumpa di Pertemuan 12.