Program Studi Bisnis Digital • FEB UNDIP

Lab Pemrograman

Pertemuan 12 — Integrasi Komponen Front-end dan Back-end dalam Satu Sistem Aplikasi

Menyatukan potongan-potongan yang selama ini dibangun terpisah — tampilan React Native, REST API, dan database — menjadi satu aplikasi bisnis digital yang benar-benar hidup dan saling berbicara.

RPS MINGGU 13 • 2 × 50 MENIT

Selamat pagi/siang, Anda semua. Sejak Pertemuan 3 kita belajar membangun tampilan dengan React Native, sejak Pertemuan 8 kita belajar membuat REST API, dan sejak Pertemuan 9 kita belajar merancang database — tapi selama ini ketiganya sering kita latih terpisah-pisah, seperti tiga potongan puzzle yang belum disatukan. Hari ini adalah hari penyatuan itu: kita akan menghubungkan tampilan aplikasi yang Anda sentuh dengan jari, ke server yang memproses logika bisnis, sampai ke database tempat data benar-benar tersimpan. Bayangkan aplikasi kasir sebuah UMKM seperti warung kopi kecil di Semarang — saat kasir mengetuk tombol "Bayar" di layar, ada perjalanan data yang panjang di baliknya sebelum struk tercetak. Setelah pertemuan ini, Anda akan paham persis perjalanan itu, karena inilah fondasi dari hampir semua aplikasi bisnis digital yang Anda pakai sehari-hari, mulai dari Tokopedia sampai aplikasi kasir UMKM.

Tujuan Pembelajaran Hari Ini

Sesuai RPS minggu 13, setelah pertemuan ini Anda diharapkan mampu mengintegrasikan komponen front-end dan back-end menjadi satu sistem aplikasi yang utuh. Secara rinci:

Konsep

Alur Data End-to-End

Memahami perjalanan data dari ketukan layar pengguna, lewat REST API, sampai tersimpan/terbaca di database, lalu kembali lagi ke layar.

Konsep

State, Loading & Error

Mampu mengelola kondisi aplikasi saat menunggu jawaban server dan saat terjadi kegagalan, tanpa membuat pengguna bingung.

Di Mana Posisi Kita Sekarang?

Selama sebelas pertemuan, kita membangun potongan-potongan sistem secara terpisah. Hari ini semua potongan itu disatukan menjadi satu aplikasi yang berjalan penuh.

Pertemuan	Apa yang Sudah Dibangun
P3–P7	Tampilan & navigasi React Native (front-end)
P8–P9	REST API & struktur database (back-end)
P10–P11	Dummy API & operasi CRUD dari GUI Python
P12 (hari ini)	Menyatukan ketiganya jadi satu sistem nyata

Tanpa integrasi, front-end hanya tampilan kosong dan back-end hanya kode yang berjalan sendirian — keduanya baru jadi "aplikasi" saat tersambung.

Bagian 1 dari 3

Arsitektur Sistem Terintegrasi

Memahami bagaimana client, server, dan database saling terhubung dalam satu sistem aplikasi yang utuh.

Anatomi Sistem: Client, Server, Database

Sistem aplikasi terintegrasi terdiri dari tiga lapisan yang saling berkirim data, bukan satu blok kode raksasa.

Client tidak pernah menyentuh database secara langsung — semua permintaan harus lewat server yang menjaga aturan dan keamanan.

Perhatikan diagram ini baik-baik, karena inilah kerangka besar yang akan kita pakai sepanjang pertemuan. Di sisi kiri ada client, yaitu aplikasi React Native yang berjalan di ponsel pengguna — inilah yang dilihat dan disentuh langsung oleh kasir atau pelanggan. Di tengah ada server, tempat REST API Flask yang sudah kita bangun di Pertemuan 8 berjalan, bertugas menjalankan logika bisnis seperti mengecek stok atau menghitung total belanja. Di sisi kanan ada database, tempat data produk, pelanggan, dan transaksi benar-benar tersimpan secara permanen. Yang penting untuk Anda catat: client tidak pernah bicara langsung ke database, semua permintaan wajib lewat server terlebih dahulu — ini mirip seperti Anda tidak bisa langsung membuka brankas bank, harus lewat teller atau ATM yang mengecek identitas dan aturan Anda dulu.

REST API: Jembatan Bahasa Client dan Server

Ingat kembali Pertemuan 8: REST API adalah kumpulan endpoint (alamat) yang menerima permintaan HTTP dan mengembalikan data, biasanya dalam format JSON.

Metode HTTP Umum

GET — ambil data (mis. daftar produk)
POST — kirim data baru (mis. transaksi baru)
PUT — ubah data yang sudah ada
DELETE — hapus data

Contoh Endpoint Kasir UMKM

GET /api/produk — daftar produk
POST /api/transaksi — simpan penjualan
PUT /api/produk/5 — ubah stok produk 5
DELETE /api/produk/5 — hapus produk 5

Alur Data End-to-End: Dari Ketukan Layar ke Database

Studi kasus: kasir mengetuk tombol "Bayar" di aplikasi React Native. Berikut perjalanan datanya, langkah demi langkah.

Langkah	Apa yang Terjadi	Di Mana
1	Kasir mengetuk tombol "Bayar"	Client (React Native)
2	Fungsi `fetch()`/`axios` mengirim POST berisi JSON transaksi	Client → Server
3	Flask menerima request, validasi data, hitung total	Server
4	Server menyimpan baris baru ke tabel `transaksi`	Server → Database
5	Server mengirim response JSON "berhasil" ke client	Server → Client
6	Layar menampilkan struk & state `loading` berhenti	Client (React Native)

Mari kita telusuri satu perjalanan data secara utuh, karena inilah inti dari integrasi front-end dan back-end. Semua dimulai dari langkah satu: kasir mengetuk tombol Bayar di layar React Native. Langkah dua, aplikasi memanggil fungsi fetch atau axios — istilahnya HTTP client — untuk mengirim data transaksi dalam format JSON ke server lewat metode POST. Langkah tiga, Flask di sisi server menerima permintaan itu, memvalidasi datanya, misalnya mengecek apakah stok cukup, lalu menghitung total belanja. Langkah empat, server menyimpan baris transaksi baru itu ke database. Langkah lima, server mengirim balik response berupa JSON yang menandakan transaksi berhasil. Dan langkah enam, aplikasi React Native menerima response itu, menampilkan struk di layar, dan menghentikan indikator loading yang tadi berputar. Seluruh proses ini biasanya hanya memakan waktu kurang dari satu detik, tapi enam langkah inilah yang membuat aplikasi terasa "hidup".

Konfigurasi Endpoint: Base URL & Environment

Front-end perlu tahu ke mana harus mengirim request. Alamat ini disimpan sebagai base URL, biasanya di satu file konfigurasi, bukan ditulis berulang di setiap layar.

// config.js — satu sumber kebenaran alamat server export const BASE_URL = "http://192.168.1.10:5000"; // dipakai di layar mana pun fetch(`${BASE_URL}/api/produk`) .then(res => res.json()) .then(data => setProduk(data));

Glosarium: base URL = alamat dasar server (mis. IP komputer dosen di jaringan lab). environment = kondisi berjalannya aplikasi (development di laptop vs production di server sungguhan) — base URL biasanya berbeda untuk tiap environment.

Salah satu kesalahan paling umum saat integrasi adalah menulis ulang alamat server di setiap layar aplikasi — kalau alamat itu berubah, Anda harus mengubahnya di puluhan tempat. Solusinya, kita simpan base URL di satu file konfigurasi seperti config.js, lalu semua layar tinggal memanggil BASE_URL itu. Perhatikan contoh kode ini: alamat 192.168.1.10 adalah contoh alamat IP lokal, misalnya laptop dosen yang menjalankan server Flask di jaringan Wi-Fi lab komputer kita. Istilah environment penting untuk Anda kenal sejak sekarang: saat kita masih belajar di kelas, environment kita disebut development, alamatnya adalah IP lokal seperti ini; nanti kalau aplikasi sungguhan dirilis ke publik, environment-nya disebut production, dan alamatnya berupa domain sungguhan seperti api.namatoko.com. Konsep ini akan sering Anda temui saat magang atau bekerja di startup nanti.

Autentikasi Terintegrasi: Token di Header Request

Ingat halaman login di Pertemuan 6. Setelah login berhasil, server memberi token yang harus disertakan di setiap request berikutnya sebagai bukti identitas.

Langkah 1

Client kirim email + password ke /api/login. Server balas token jika cocok.

Langkah 2

Header Authorization

Setiap request berikutnya menyertakan token di header: Authorization: Bearer <token>.

Tanpa token yang valid, server menolak request dengan status 401 Unauthorized — ini melindungi data seperti riwayat transaksi agar tidak diakses sembarang orang.

Sekarang kita hubungkan halaman login yang kita bangun di Pertemuan 6 dengan mekanisme keamanan back-end. Setelah kasir berhasil login dengan email dan kata sandi yang benar, server tidak hanya bilang "berhasil", tapi juga memberikan sebuah token — semacam kartu identitas digital sementara. Token ini kemudian disimpan di aplikasi React Native, dan disertakan di setiap request berikutnya lewat bagian header bernama Authorization, dengan format Bearer diikuti tokennya. Kalau ada yang mencoba mengakses data transaksi tanpa token yang valid, server akan menolak dengan kode status 401 Unauthorized — ini penting supaya, misalnya, data penjualan sebuah toko tidak bisa diintip oleh siapa saja yang kebetulan tahu alamat API-nya. Bayangkan seperti kartu akses karyawan di kantor: tanpa kartu yang sah, pintu tidak akan terbuka.

Hitung dari Nol: Waktu Respons Total Alur Login

Aplikasi kasir UMKM login lewat jaringan Wi-Fi lab. Empat tahap request-response punya waktu masing-masing. Berapa total waktu sampai layar menampilkan hasil?

Langkah	Perhitungan	Nilai
1. Request dikirim client → server	latensi jaringan	120 ms
2. Server validasi & hitung logika	waktu proses server	80 ms
3. Query ke database mengambil data user	waktu query	45 ms
4. Response dikirim server → client	latensi jaringan	120 ms
5. Total waktu respons	120 + 80 + 45 + 120	365 ms

Total Waktu Login

365 ms

Mari kita hitung berapa lama sebenarnya proses login yang terasa "instan" bagi pengguna. Langkah pertama, request dari aplikasi React Native butuh waktu seratus dua puluh milidetik untuk sampai ke server lewat jaringan Wi-Fi lab. Langkah kedua, server Flask memvalidasi email dan kata sandi, membutuhkan delapan puluh milidetik. Langkah ketiga, server melakukan query ke database untuk mencocokkan data pengguna, memakan waktu empat puluh lima milidetik. Langkah keempat, response hasilnya dikirim kembali ke client, butuh seratus dua puluh milidetik lagi karena jaraknya sama seperti saat berangkat. Kalau kita jumlahkan seratus dua puluh ditambah delapan puluh ditambah empat puluh lima ditambah seratus dua puluh, hasilnya tiga ratus enam puluh lima milidetik, atau kurang dari setengah detik. Angka inilah yang menjelaskan mengapa kita tetap perlu menampilkan indikator loading walau prosesnya terasa cepat — mata manusia mulai menyadari jeda di atas seratus milidetik.

Coba Sendiri: Hitung Total Latensi Alur Login

Ubah waktu tiap tahap request-response, lalu amati bagaimana total waktu yang dirasakan pengguna berubah.

Hitung dari Nol: Efisiensi Data dengan Pagination

Database sebuah toko online punya 500 produk, tiap produk dalam format JSON berukuran 2 KB. Bandingkan kirim semua sekaligus vs kirim per halaman (pagination) 20 produk.

Langkah	Perhitungan	Nilai
1. Total produk di database	—	500 record
2. Ukuran rata-rata per record JSON	—	2 KB
3. Tanpa pagination: total data terkirim	500 × 2 KB	1.000 KB
4. Dengan pagination (20/halaman): data per request	20 × 2 KB	40 KB
5. Penghematan data	(1.000 − 40) ÷ 1.000 × 100%	96%

Penghematan per Request

96%

Contoh ini menunjukkan mengapa pagination — teknik memecah data jadi halaman-halaman kecil — sangat penting saat integrasi front-end dan back-end. Bayangkan database toko online kita menyimpan lima ratus produk, masing-masing dalam format JSON berukuran kira-kira dua kilobyte. Kalau aplikasi React Native meminta seluruh data sekaligus tanpa pagination, server harus mengirim lima ratus dikali dua kilobyte, sama dengan seribu kilobyte, atau sekitar satu megabyte, hanya untuk satu kali buka halaman produk. Bandingkan kalau kita menerapkan pagination dengan dua puluh produk per halaman: data yang dikirim per request hanya dua puluh dikali dua kilobyte, yaitu empat puluh kilobyte. Kalau kita hitung penghematannya, seribu dikurangi empat puluh dibagi seribu dikali seratus persen, hasilnya sembilan puluh enam persen lebih hemat. Bagi pengguna di jaringan seluler yang tidak selalu stabil, seperti pelanggan UMKM di daerah dengan sinyal 4G terbatas, penghematan sebesar ini sangat terasa pada kecepatan loading aplikasi.

Bagian 2 dari 3

Loading, Error, dan State Terintegrasi

Bagaimana aplikasi menampilkan kondisi "sedang bekerja" dan "terjadi masalah" agar pengguna tidak bingung.

Loading State: Menunggu Jawaban Server dengan Elegan

Selama request berjalan (365 milidetik dari contoh Slide 10, atau bisa lebih lama), aplikasi harus memberi tahu pengguna bahwa sistem sedang bekerja — bukan diam membisu.

const [loading, setLoading] = useState(false); const bayarTransaksi = async () => { setLoading(true); // tampilkan spinner const res = await fetch(`${BASE_URL}/api/transaksi`, { method: "POST", body: JSON.stringify(data) }); setLoading(false); // sembunyikan spinner }; // di JSX: {loading ? <Spinner /> : <TombolBayar />}

Ingat Pertemuan 5: loading adalah state biasa — setiap kali nilainya berubah, React Native otomatis menggambar ulang tampilan yang relevan.

Ingat kembali konsep state dari Pertemuan 5 — hari ini kita pakai state untuk kebutuhan yang sangat praktis: menandai apakah aplikasi sedang menunggu jawaban server atau tidak. Perhatikan kode ini: sebelum mengirim request, kita set loading menjadi true, sehingga tampilan otomatis berganti menjadi spinner berputar. Setelah request selesai, baik berhasil maupun gagal, kita set loading kembali menjadi false, sehingga tombol bayar muncul kembali. Tanpa pola ini, kasir yang menekan tombol bayar dan tidak melihat respons apa pun dalam sepersekian detik cenderung menekan tombol itu berkali-kali, yang bisa menyebabkan transaksi tercatat dua kali di database — bug yang sering terjadi di aplikasi buatan pemula. Loading state yang jelas adalah salah satu penanda aplikasi yang matang secara pengalaman pengguna, atau UX.

Error Handling Terintegrasi: Saat Sesuatu Gagal

Server bisa menjawab dengan berbagai status code. Front-end harus mengenali dan meresponsnya dengan pesan yang dipahami pengguna, bukan layar kosong atau aplikasi crash.

Status Code Umum

200 OK — berhasil
400 Bad Request — data salah format
401 Unauthorized — token tidak valid
404 Not Found — data tidak ditemukan
500 Server Error — server bermasalah

Pola try/catch di React Native

try — jalankan request
catch — tangkap kegagalan jaringan
Tampilkan pesan: "Koneksi bermasalah, coba lagi"

Aplikasi yang baik tidak pernah membiarkan pengguna menatap layar kosong tanpa penjelasan saat terjadi masalah. Di sisi kiri, lima status code ini adalah kosakata wajib yang harus Anda kenali: dua ratus artinya semua lancar, empat ratus artinya ada yang salah dari sisi data yang kita kirim, empat ratus satu artinya token login kita sudah tidak berlaku, empat ratus empat artinya data yang dicari memang tidak ada, dan lima ratus artinya justru server-nya yang bermasalah, bukan salah kita. Di sisi kanan, pola try dan catch dalam JavaScript memungkinkan kita "menangkap" kegagalan seperti koneksi internet yang putus tiba-tiba, misalnya saat kasir sedang berada di area dengan sinyal lemah, lalu menampilkan pesan yang mudah dipahami seperti "Koneksi bermasalah, coba lagi" alih-alih membiarkan aplikasi berhenti bekerja tanpa penjelasan.

CRUD Penuh: Form React Native → API → Database

Ingat Pertemuan 11 (CRUD dari GUI Python). Pola yang sama kini kita terapkan di React Native, tersambung ke back-end sungguhan.

Operasi CRUD	Aksi di Layar React Native	Endpoint yang Dipanggil
Create	Isi form produk baru, tekan "Simpan"	`POST /api/produk`
Read	Buka halaman daftar produk	`GET /api/produk`
Update	Ubah harga di form edit, tekan "Perbarui"	`PUT /api/produk/5`
Delete	Tekan ikon hapus pada satu produk	`DELETE /api/produk/5`

Setelah tiap operasi berhasil, layar harus memuat ulang daftar data (panggil ulang GET) agar tampilan selalu sesuai isi database terbaru.

Slide ini adalah jembatan langsung ke Pertemuan 11, di mana Anda sudah berlatih operasi CRUD dari antarmuka GUI Python terhadap dummy API. Sekarang kita pindahkan pola yang sama persis ke React Native, hanya saja back-end-nya sudah bukan dummy lagi, melainkan Flask dan database sungguhan. Perhatikan pola konsistennya: Create memakai metode POST saat kasir menambah produk baru misalnya "Kopi Susu Gula Aren", Read memakai metode GET saat membuka halaman daftar produk, Update memakai metode PUT saat mengubah harga produk yang sudah ada, dan Delete memakai metode DELETE saat menghapus produk yang sudah tidak dijual. Satu kebiasaan penting yang sering dilupakan pemula: setelah operasi create, update, atau delete berhasil, aplikasi harus memanggil ulang endpoint GET supaya daftar yang ditampilkan di layar benar-benar mencerminkan kondisi database terkini — kalau tidak, pengguna bisa melihat data yang sudah usang.

Bagian 3 dari 3

Studi Kasus & Debugging Sistem Terintegrasi

Merangkai semua komponen dalam satu studi kasus aplikasi kasir UMKM, lalu belajar mencari sumber masalah saat sistem tidak berjalan mulus.

Studi Kasus: Aplikasi Kasir UMKM End-to-End

Warung "Kopi Bu Warsih" ingin aplikasi kasir. Berikut potongan kode React Native yang menyatukan fetch data, tampilkan, dan kirim transaksi.

useEffect(() => { setLoading(true); fetch(`${BASE_URL}/api/produk`, { headers: { Authorization: `Bearer ${token}` } }) .then(res => res.json()) .then(data => setProdukList(data)) .catch(() => setError("Gagal memuat produk")) .finally(() => setLoading(false)); }, []); // dipanggil sekali saat layar dibuka

Perhatikan: token (Slide 9) dikirim di header, loading (Slide 13) dikelola, dan catch (Slide 14) menangani kegagalan — tiga konsep hari ini bertemu dalam satu fungsi.

Kode ini adalah rangkuman praktik dari seluruh materi hari ini, dipasang di layar utama aplikasi kasir warung Bu Warsih. useEffect adalah fungsi React Native yang otomatis berjalan saat layar pertama kali dibuka — di dalamnya kita set loading menjadi true, lalu memanggil endpoint GET slash api slash produk dengan menyertakan token di header Authorization seperti yang kita bahas di Slide 9. Kalau permintaan berhasil, data produk disimpan ke state produkList sehingga tampil di layar. Kalau gagal, misalnya karena sinyal Wi-Fi warung sedang buruk, bagian catch akan menyimpan pesan error yang bisa kita tampilkan ke kasir. Dan apa pun hasilnya, berhasil atau gagal, bagian finally memastikan loading kembali menjadi false sehingga spinner berhenti berputar. Coba perhatikan bagaimana tiga konsep yang kita pelajari terpisah — autentikasi, loading state, dan error handling — ternyata bertemu secara alami dalam satu fungsi nyata seperti ini.

Debugging Sistem Terintegrasi: Di Mana Mencari Masalah?

Saat aplikasi "tidak jalan", masalahnya bisa ada di salah satu dari tiga lapisan. Periksa berurutan, jangan menebak.

1. Cek Client
Apakah BASE_URL benar? Apakah fetch/axios memakai method & body yang sesuai?

2. Cek Server
Buka log Flask di terminal — apakah request diterima? Apakah ada pesan error saat validasi?

3. Cek Database
Apakah tabel & kolom sesuai dengan yang diharapkan query di Pertemuan 9?

Alat bantu: console.log() di client, print() di Flask, dan lihat langsung isi tabel database — tiga jendela ini membongkar 90% masalah integrasi.

Ketika aplikasi tidak berjalan seperti yang diharapkan, kebiasaan buruk pemula adalah menebak-nebak dan mengubah kode secara acak. Cara yang benar adalah memeriksa tiga lapisan secara berurutan seperti detektif. Pertama, cek sisi client: pastikan BASE_URL yang kita bahas di Slide 8 sudah benar, dan pastikan method HTTP serta data yang dikirim sudah sesuai format yang diharapkan server. Kedua, kalau client sudah benar tapi tetap gagal, cek sisi server dengan membuka jendela terminal tempat Flask berjalan — biasanya akan muncul log yang menunjukkan apakah request benar-benar sampai dan di mana validasinya gagal. Ketiga, kalau server bilang berhasil tapi data tidak sesuai harapan, cek langsung isi tabel database, siapa tahu nama kolom yang dipakai query berbeda dengan yang kita rancang di Pertemuan 9. Dengan membuka tiga jendela ini secara bersamaan — layar aplikasi, terminal server, dan isi database — Anda bisa menemukan sumber masalah jauh lebih cepat daripada menebak.

Latihan Kelas: Sambungkan Layar Daftar Produk ke API

Kerjakan berpasangan, 20 menit. Gunakan proyek React Native dan Flask dari Pertemuan 8–11 yang sudah Anda miliki.

Instruksi

Buat state loading, produkList, dan error (rujuk Slide 13–14)
Panggil GET /api/produk di dalam useEffect saat layar dibuka
Tampilkan spinner saat loading, pesan error saat gagal, daftar produk saat berhasil
Tambahkan tombol "Hapus" yang memanggil DELETE /api/produk/:id, lalu muat ulang daftar

Gunakan checklist debugging di Slide 18 kalau ada langkah yang tidak berjalan — periksa client, server, lalu database secara berurutan.

Sekarang giliran Anda mempraktikkan integrasi secara langsung. Silakan berpasangan dengan teman sebelah, dan Anda punya waktu dua puluh menit menggunakan proyek React Native serta Flask yang sudah dibangun sejak Pertemuan 8 sampai 11 — tidak perlu memulai dari nol. Langkah pertama, siapkan tiga state seperti pada Slide 13 dan 14: loading, produkList, dan error. Langkah kedua, panggil endpoint GET slash api slash produk di dalam useEffect supaya data otomatis dimuat saat layar dibuka. Langkah ketiga, pastikan tampilan berubah sesuai kondisi: spinner saat loading, pesan error saat gagal, dan daftar produk saat berhasil. Langkah keempat, sebagai tantangan tambahan, buat tombol hapus yang memanggil endpoint DELETE, lalu jangan lupa memuat ulang daftar produk setelah penghapusan berhasil, persis seperti yang kita bahas di Slide 15. Kalau ada bagian yang macet, gunakan checklist debugging tiga lapisan dari slide sebelumnya sebelum bertanya ke saya.

Rangkuman & Menuju Pertemuan 13

Istilah	Arti Singkat
Base URL	Alamat dasar server yang dituju semua request
Token / Authorization	Bukti identitas yang disertakan di header tiap request
Loading state	Kondisi aplikasi sedang menunggu jawaban server
try/catch	Pola menangkap & menangani kegagalan request
Pagination	Mengirim data per halaman untuk hemat bandwidth

Pertemuan 13: Evaluasi, debugging, dan penyusunan laporan proyek akhir secara sistematis. Tugas: pastikan latihan Slide 19 berjalan penuh (loading, error, dan hapus data) sebagai fondasi proyek akhir Anda.

Mari kita rangkum perjalanan panjang hari ini lewat tabel istilah di layar — saya sarankan Anda foto atau salin tabel ini sebagai catatan cepat, karena semua istilah ini akan langsung dipakai di proyek akhir Anda. Kita sudah belajar bahwa base URL adalah alamat tunggal tempat semua request dituju, token adalah bukti identitas yang menjaga keamanan data, loading state membuat pengguna tahu aplikasi sedang bekerja, pola try dan catch menangani kegagalan dengan elegan, dan pagination menghemat data yang dikirim lewat jaringan. Minggu depan, di Pertemuan 13, kita akan masuk ke tahap evaluasi dan debugging sistem terintegrasi secara sistematis, sekaligus mulai menyusun laporan proyek akhir Anda. Sebelum pertemuan berikutnya, tolong pastikan latihan dari Slide 19 benar-benar berjalan penuh — loading, penanganan error, dan operasi hapus data — karena inilah fondasi yang akan Anda pakai untuk proyek akhir aplikasi bisnis digital Anda sendiri. Sampai jumpa di pertemuan berikutnya!