Kenapa seorang developer justru bisa lebih menyukai blockchain yang relatif kecil ketika sedang melakukan test build project, mencoba sebuah ide, atau mengembangkan DApp Web3?
Menurut kami, berdasarkan pengalaman kami sendiri di Tim Developer Crypto Receh ketika membangun dan menguji berbagai eksperimen Web3, ada dua faktor utama yang membuat sebuah blockchain kecil terasa menarik bagi developer.
Pertama adalah biaya transaksi yang murah, termasuk harga native coin yang digunakan untuk membayar gas fee.
Kedua dan menurut kami justru yang paling penting, adalah ketersediaan RPC dengan rate limit yang tidak terlalu membatasi aktivitas developer.
Gas Fee Murah Memang Penting, Tetapi Bukan Satu-satunya Masalah
Ketika membangun DApp, biaya transaksi memang menjadi salah satu pertimbangan pertama.
Developer tentu tidak ingin menghabiskan terlalu banyak dana hanya untuk melakukan testing berulang kali. Dalam proses development, satu fungsi smart contract bisa saja dipanggil puluhan atau bahkan ratusan kali. Belum lagi ketika harus melakukan deployment ulang contract, melakukan transaksi percobaan, menguji approval token, swap, liquidity, staking, claim reward, bridge dan berbagai fungsi lainnya.
Karena itu, blockchain dengan gas fee murah memberikan ruang eksperimen yang jauh lebih besar.
Namun dari pengalaman kami, setelah sebuah DApp mulai memiliki banyak fungsi dan membutuhkan banyak pembacaan data on-chain, persoalannya tidak lagi hanya tentang gas fee.
Di titik tersebut, RPC justru bisa menjadi salah satu bottleneck terbesar.
RPC Public Gratis Sangat Berguna, Tetapi Ada Batasnya
Jangan salah memahami RPC.
Untuk kebutuhan sederhana seperti menghubungkan wallet, membaca saldo, melakukan transfer token, atau melakukan beberapa transaksi dasar, public RPC biasanya sudah lebih dari cukup.
Masalah mulai terasa ketika kita membangun sebuah DApp yang membutuhkan banyak query ke blockchain.
Sebuah interface DApp bisa saja harus membaca berbagai data secara bersamaan, misalnya:
- native coin balance;
- token balance;
- allowance;
- informasi pair;
- reserve liquidity;
- harga token;
- data pool;
- status staking;
- reward yang tersedia;
- data referral;
- event contract;
- informasi transaksi;
- status approval;
- dan berbagai state smart contract lainnya.
Semakin kompleks DApp yang dibuat, semakin banyak pula RPC call yang dibutuhkan.
Di sinilah developer mulai berhadapan dengan rate limit.
Masalahnya Bukan RPC Tidak Bisa Digunakan
Persoalannya bukan berarti public RPC tidak bagus atau tidak bisa digunakan.
Justru public RPC sangat membantu developer karena memungkinkan kita berinteraksi dengan blockchain tanpa harus menjalankan infrastruktur node sendiri.
Masalahnya adalah ketika kebutuhan sebuah DApp sudah melewati pola penggunaan sederhana.
Misalnya sebuah halaman DApp harus melakukan banyak eth_call untuk mendapatkan data contract. Kemudian pengguna berpindah halaman, melakukan refresh, membuka dashboard, mengecek balance, membaca informasi pool dan melakukan beberapa interaksi lainnya.
Semua aktivitas tersebut membutuhkan komunikasi antara aplikasi dengan blockchain.
Jika endpoint RPC yang digunakan memiliki batas request tertentu, maka developer akan mulai melihat berbagai masalah seperti request gagal, data terlambat muncul, error sementara, atau aplikasi terasa tidak responsif.
Padahal smart contract-nya sendiri bisa saja berjalan dengan normal.
Dengan kata lain, yang menjadi masalah bukan blockchain atau smart contract-nya, tetapi jalur komunikasi antara DApp dan blockchain melalui RPC.
Menggunakan RPC Berbayar?
Tentu ada solusi.
Developer bisa menggunakan layanan RPC berbayar dengan kapasitas request yang lebih besar, fitur yang lebih lengkap dan infrastruktur yang memang dirancang untuk kebutuhan production.
Tetapi ada konsekuensinya: biaya.
Untuk sebuah perusahaan atau project dengan pengguna besar, biaya tersebut mungkin merupakan bagian normal dari infrastruktur.
Namun bagi developer yang sedang bereksperimen, membuat prototype, menguji ide baru, atau membangun project secara mandiri, biaya infrastruktur bisa menjadi pertimbangan tersendiri.
Belum tentu setiap eksperimen akan menjadi produk komersial.
Kadang developer hanya ingin menjawab pertanyaan sederhana:
“Apakah ide ini benar-benar bisa berjalan di blockchain?”
Untuk menjawab pertanyaan tersebut, tentu akan sangat membantu jika developer bisa melakukan eksperimen tanpa harus langsung memikirkan biaya infrastruktur yang besar.
Bagaimana dengan Menjalankan Node Sendiri?
Alternatif lainnya adalah menjalankan node sendiri dan menyediakan private RPC.
Secara teknis, pendekatan ini memberikan kontrol yang jauh lebih besar terhadap infrastruktur.
Developer tidak lagi sepenuhnya bergantung pada public RPC provider.
Namun konsekuensinya juga lebih besar.
Menjalankan node berarti membutuhkan server, storage, bandwidth, monitoring, maintenance, sinkronisasi blockchain, konfigurasi keamanan, serta berbagai kebutuhan operasional lainnya.
Untuk project tertentu, menjalankan node sendiri memang merupakan pilihan yang masuk akal.
Tetapi untuk developer yang hanya ingin melakukan eksperimen atau membangun prototype, biaya dan kompleksitas tersebut bisa menjadi penghalang tambahan.
Di Sinilah Blockchain Kecil Menjadi Menarik
Menurut pengalaman kami, di sinilah blockchain yang relatif kecil bisa memberikan pengalaman development yang menarik.
Bukan semata-mata karena blockchain tersebut memiliki fitur yang lebih banyak daripada blockchain besar.
Justru salah satu daya tariknya adalah ruang eksperimen yang lebih longgar.
Jika gas fee murah, native coin murah dan akses RPC dapat digunakan dengan lebih leluasa, developer bisa melakukan lebih banyak eksperimen dengan biaya dan hambatan infrastruktur yang lebih rendah.
Developer bisa melakukan deployment contract, melakukan transaksi percobaan, membaca state contract berkali-kali, menguji integrasi frontend, mengembangkan indexer sederhana, mencoba berbagai metode query, hingga menguji perilaku DApp secara langsung.
Dan menurut kami, pengalaman seperti ini sangat berharga.
Kami Lebih Suka Praktik Langsung di Mainnet
Ada satu hal lain yang menjadi alasan kami cukup menyukai pendekatan ini.
Kami pribadi lebih menyukai praktik langsung di mainnet daripada terlalu bergantung pada testnet.
Bukan berarti testnet tidak berguna.
Testnet tetap memiliki fungsi penting untuk pengujian awal, terutama ketika sebuah sistem masih dalam tahap pengembangan dan membutuhkan banyak eksperimen tanpa risiko biaya aset bernilai nyata.
Namun ada perbedaan pengalaman antara testnet dan mainnet.
Ketika kita langsung menggunakan mainnet dengan biaya transaksi yang sangat murah, kita bisa melihat kondisi yang benar-benar terjadi pada jaringan tersebut.
Kita dapat mengetahui bagaimana transaksi diproses, bagaimana RPC merespons, bagaimana smart contract berinteraksi dengan jaringan, bagaimana wallet berperilaku, bagaimana block explorer membaca transaksi dan bagaimana DApp bekerja dalam kondisi jaringan yang sebenarnya.
Dengan demikian, kita tidak hanya menguji apakah kode kita secara teori dapat berjalan, tetapi juga menguji kompatibilitas EVM dan integrasi seluruh komponen DApp pada jaringan tersebut.
Contohnya Ketika Membangun DApp di BSC
Ambil contoh ketika kita membangun sebuah DApp di BSC.
BSC memiliki ekosistem yang besar dan banyak infrastruktur pendukung. Namun bagi developer, penggunaan RPC tetap memiliki batasan tergantung endpoint dan provider yang digunakan.
Untuk DApp sederhana, hal tersebut mungkin tidak terlalu terasa.
Tetapi ketika aplikasi mulai memiliki banyak fungsi yang membutuhkan pembacaan data on-chain secara terus-menerus, kebutuhan RPC juga meningkat.
Misalnya sebuah DEX membutuhkan informasi token, pair, reserve, price, allowance, balance, routing dan berbagai data lainnya. Dashboard staking juga membutuhkan informasi jumlah staking, reward, lock period, referral dan data contract lainnya.
Semua itu pada akhirnya kembali ke satu hal:
Seberapa banyak request yang bisa kita lakukan ke blockchain melalui RPC?
Kalau request dibatasi terlalu ketat, developer harus mulai mengoptimalkan cara aplikasi mengambil data, melakukan caching, batching, membuat backend/indexer, atau menggunakan infrastruktur RPC yang lebih besar.
Semua solusi tersebut valid, tetapi semuanya menambah kompleksitas.
RPC Adalah Bagian Penting dari Infrastruktur DApp
Menurut kami, developer Web3 terkadang terlalu fokus pada smart contract dan gas fee, sementara RPC justru merupakan bagian yang sangat penting dari keseluruhan arsitektur DApp.
Smart contract bisa aman dan berfungsi dengan baik.
Frontend bisa dibuat dengan sangat baik.
Wallet integration juga bisa berjalan normal.
Tetapi jika aplikasi tidak dapat mengambil data blockchain secara konsisten karena keterbatasan RPC, pengalaman pengguna tetap akan bermasalah.
Karena itu, ketika memilih jaringan untuk sebuah eksperimen DApp, kami tidak hanya melihat:
- berapa harga gas;
- berapa cepat transaksi dikonfirmasi;
- apakah EVM compatible;
- berapa besar ekosistemnya.
Kami juga melihat satu hal yang sering kali baru terasa setelah development berjalan:
Bagaimana akses RPC pada jaringan tersebut?
Bukan Berarti Blockchain Kecil Selalu Lebih Baik
Tentu saja, ini bukan berarti blockchain kecil selalu menjadi pilihan yang tepat untuk setiap project.
Blockchain dengan ekosistem besar memiliki keunggulan tersendiri: lebih banyak liquidity, wallet, developer tools, infrastructure provider, explorer, exchange, library dan pengguna.
Untuk aplikasi production dengan kebutuhan pengguna yang besar, faktor-faktor tersebut tentu harus diperhitungkan.
Namun untuk tahap eksplorasi, prototype, research dan pengembangan ide DApp, pengalaman kami menunjukkan bahwa blockchain kecil dengan biaya rendah dan akses RPC yang lebih longgar dapat menjadi lingkungan eksperimen yang menarik.
Kesimpulan dari Pengalaman Kami
Jadi, kenapa kami menyukai blockchain kecil untuk melakukan test build atau mencoba ide pengembangan DApp Web3 misalnya Receh Staking, Receh DEX dan DApp kami lainnya?
Bukan hanya karena gas fee murah.
Menurut kami, kombinasi antara native coin yang murah, biaya transaksi rendah, EVM compatibility dan akses RPC yang lebih leluasa justru memberikan ruang eksperimen yang sangat besar bagi developer.
Terutama ketika kita membangun DApp yang membutuhkan banyak query on-chain.
Karena pada akhirnya, tantangan developer Web3 bukan hanya bagaimana membuat smart contract yang berjalan.
Kita juga harus memikirkan bagaimana frontend membaca blockchain, bagaimana wallet berinteraksi dengan contract, bagaimana data on-chain diambil, bagaimana RPC menangani request, bagaimana transaksi dikonfirmasi dan bagaimana seluruh komponen tersebut bekerja sebagai satu sistem.
Dan dari pengalaman kami sendiri, keterbatasan RPC bisa menjadi salah satu tantangan terbesar dalam pengembangan DApp Web3, bahkan ketika gas fee bukan lagi masalah utama.
Itulah alasan mengapa, untuk eksperimen tertentu, kami justru menikmati membangun langsung di blockchain yang lebih kecil: biaya lebih ringan, ruang eksperimen lebih luas dan kita bisa melihat secara langsung bagaimana ide tersebut benar-benar bekerja di jaringan EVM yang digunakan.
