Belajar Web3 - DApp Architecture Overview

#Pendahuluan

Setelah di episode 2 kita memetakan arsitektur Web3 secara makro, pada episode ini kita mempersempit fokus: bagaimana sebuah DApp tunggal disusun dan bagaimana data mengalir di dalamnya. Ini adalah jembatan dari teori ke kode — mulai episode 9 kita akan membangunnya sungguhan.

Mengapa episode ini penting? Karena DApp adalah aplikasi hybrid: sebagian state ada on-chain (yang benar-benar desentral), sebagian lagi di server/frontend (yang praktis). Developer yang tidak paham batas ini akan membangun "aplikasi web biasa yang menempel tombol connect wallet" tanpa desain arsitektur yang benar.

#Lapisan DApp

Sebuah DApp terdiri dari tiga lapisan:

#Frontend (React/Next.js + wagmi)

Antarmuka user. Ini tempat wagmi (hooks React) dan viem (low-level library) bekerja. Frontend tidak menyimpan data penting — ia menjadi "remote" yang menampilkan state on-chain dan memicu transaksi.

#Contract Layer (EVM/Solana)

Logika bisnis yang berjalan on-chain. Di EVM ini smart contract Solidity; di Solana ini program Rust. Lapisan ini adalah satu-satunya bagian yang benar-benar terdesentralisasi — tidak bisa diubah sewenang-wenang oleh developer.

#Infrastruktur (RPC, Indexer, IPFS)

Lapisan pendukung: RPC node untuk komunikasi, indexer (The Graph) untuk query efisien, dan storage (IPFS/Arweave) untuk file besar. Infrastruktur ini biasanya disediakan pihak ketiga, sehingga DApp bisa berjalan tanpa menjalankan node sendiri.

#Alur Kerja DApp

Setiap interaksi DApp mengikuti empat langkah yang sama:

#1. Connect Wallet

User menghubungkan wallet (MetaMask) ke frontend. Frontend kini tahu address user dan bisa membaca state atas nama mereka. Detail implementasi di episode 10.

#2. Read State

Frontend memanggil fungsi read contract — misalnya balanceOf(address) atau totalSupply(). Read adalah eth_call: tidak butuh gas, tidak mengubah state, dan tidak menandatangani apa pun.

const balance = await publicClient.readContract({
  address: tokenAddress,
  abi: erc20Abi,
  functionName: "balanceOf",
  args: [userAddress],
})

#3. Sign & Broadcast (Write)

Untuk operasi yang mengubah state — transfer, approve, mint — user menandatangani transaksi di wallet lalu menyiarkannya. Operasi ini membayar gas dan butuh konfirmasi blok.

#4. Update UI via Event

Setelah transaksi terkonfirmasi, frontend memperbarui UI. Bisa dengan menunggu receipt, atau mendengarkan event (misalnya event Transfer) yang dipancarkan contract.

#Pola "Bagian yang Terpusat"

Jujur soal arsitektur: sebagian DApp tetap memakai bagian terpusat. Contoh sah yang umum:

• Frontend hosting di Vercel/Netlify — halaman web tidak perlu on-chain.
• Off-chain data seperti metadata NFT (episode 13) — file besar tidak ekonomis di chain.
• Indexer pihak ketiga — query cepat di luar chain.

#Ringkasan Konsep

Rangkuman yang sudah kalian pelajari di episode 5:

• DApp = frontend (wagmi) + contract layer + infrastruktur (RPC/indexer/IPFS).
• Alur kerja standar: connect wallet → read state → sign & broadcast → update UI via event.
• Read tidak butuh gas; write butuh gas dan signature.
• Sebagian infrastruktur boleh terpusat selama state kritis tetap on-chain.

#Penutup

Inti yang harus dibawa pulang:

• Desain DApp selalu mulai dari pertanyaan: "state mana yang harus on-chain, mana yang tidak?"
• Setiap tombol "submit" di DApp adalah alur 4 langkah: connect, read, write, event.
• Bedakan read (gratis) dan write (berbayar) — ini menentukan UX dan biaya aplikasi kalian.

Di episode 6 selanjutnya, kita mereview smart contract dasar (EVM) — storage/memory/calldata, ABI dan function selector, serta standar token ERC-20, ERC-721, ERC-1155, dan ERC-2981 yang akan kalian hadapi setiap hari sebagai developer DApp. Sampai jumpa di episode 6!