Belajar Web3 - RPC & Infrastructure

#Pendahuluan

Setelah di episode 14 kita memindahkan beban query ke indexer, pada episode ini kita merapikan jembatan komunikasi utama DApp: RPC. Setiap kali frontend membaca state atau menyiarkan transaksi, ia bicara ke RPC node. Kegagalan di lapisan ini — rate limit, endpoint down, chain salah — adalah penyebab paling umum "DApp tidak jalan".

Mengapa episode ini penting? Karena sebagian besar DApp produksi bukan menjalankan node sendiri, melainkan bergantung pada provider. Memahami model biaya, rate limit, dan strategi fallback menentukan apakah aplikasi kalian tetap jalan saat satu provider bermasalah.

#Provider RPC

Perbandingan penyedia RPC utama:

Semua punya free tier yang cukup untuk development. Untuk produksi, upgrade ke tier berbayar — terutama jika DApp melayani banyak user (rate limit publik sangat ketat).

#Rate Limiting

Provider membatasi jumlah request per detik per endpoint. Dampaknya pada arsitektur frontend:

• Setiap komponen yang memanggil hook read berkontribusi pada kuota.
• useReadContract dengan argumen sama memakai cache react-query — jangan abaikan manfaat cache.
• Polling agresif (episode 12) adalah pemboros kuota terbesar.

Pola yang benar: cache sebanyak mungkin, batasi refetch, dan tempatkan panggilan kritis pada kebutuhan nyata.

#Fallback Providers

Satu endpoint = single point of failure. viem mendukung fallback transport: coba provider pertama, gagal, otomatis pindah ke provider berikutnya.

import { http, createConfig, fallback } from "wagmi"
import { sepolia } from "wagmi/chains"
 
const transport = fallback([
  http(`https://eth-sepolia.g.alchemy.com/v2/${import.meta.env.VITE_ALCHEMY_KEY}`),
  http(`https://sepolia.infura.io/v3/${import.meta.env.VITE_INFURA_KEY}`),
  http("https://rpc.sepolia.org"),
])
 
export const wagmiConfig = createConfig({
  chains: [sepolia],
  transports: { [sepolia.id]: transport },
})

Susun urutan dari yang paling tepercaya ke publik — fallback hanya aktif saat provider utama gagal atau rate limited.

#Public vs Dedicated Node

Jangan menaruh DApp produksi di public RPC — pengalaman umumnya buruk saat traffic naik. Setidaknya gunakan free tier provider dengan fallback.

#Light Client: Tren 2026

Light client adalah node yang tidak menyimpan seluruh blockchain, tetapi memverifikasi data lewat header blok dan bukti kriptografis. Di 2026, pengalaman light client semakin matang dan mulai dipakai sebagai lapisan verifikasi di aplikasi konsumen — misalnya memvalidasi data RPC tanpa mempercayai provider sepenuhnya.

Implikasi bagi developer: arah arsitektur bergeser dari "percaya penuh pada provider RPC" menuju verifikasi mandiri — provider tetap menjadi jalur data, tetapi bukti (proof) membuat klaim mereka bisa dicek. Untuk sekarang, pahami bahwa RPC adalah lapisan infrastruktur yang tidak harus dipercaya buta.

#Ringkasan Konsep

Rangkuman yang sudah kalian pelajari di episode 15:

• Pilih provider sesuai kebutuhan; free tier cukup untuk development.
• Rate limit adalah batas nyata — cache dan kurangi polling.
• Fallback transport membuat DApp bertahan saat satu provider gagal.
• Public node untuk prototipe; dedicated node untuk produksi.
• Light client (2026) memungkinkan verifikasi mandiri tanpa menjalankan node penuh.

#Penutup

Inti yang harus dibawa pulang:

• RPC adalah jalur hidup DApp — jangan biarkan single point of failure.
• Env variable untuk API key; jangan pernah hardcode di bundle (episode 16).
• Desain dari awal: fallback + cache + indexer = infrastruktur yang sehat.

Di episode 16 selanjutnya, kita membahas keamanan DApp & wallet — perlindungan private key, phishing signature, limit allowance dan revoke.cash, verifikasi source contract, audit dependency, serta nonce/replay protection. Ini salah satu episode paling penting di series ini. Sampai jumpa di episode 16!