NEAR untuk Pengembang Backend: Kemampuan Anda, Terdesentralisasi

Pengantar
Jika Anda membangun backend hari ini, Anda sudah tahu cara merancang API, menyimpan status, dan mengelola pengguna. Protokol NEAR memungkinkan Anda menggunakan insting yang sama—hanya pada jaringan terdesentralisasi alih-alih server Anda sendiri. Pikirkan NEAR sebagai “backend yang tidak perlu Anda host.” Logika bisnis Anda berjalan sebagai kontrak pintar (program mini), data Anda berada di dalam toko yang direplikasi yang dikelola oleh jaringan, dan identitas pengguna diverifikasi oleh kriptografi, bukan kata sandi. Dalam pelajaran ini, kita akan memetakan ide backend yang akrab ke konsep NEAR, menjelajahi contoh sederhana gaya Twitter, dan menunjukkan bagaimana pembacaan dan penulisan bekerja. Pada akhirnya, Anda akan melihat bahwa beralih dari web2 ke NEAR adalah adaptasi—bukan reinkarnasi.

NEAR sebagai Backend Terdesentralisasi

Bayangkan mendeploy layanan yang berjalan pada klaster global yang tidak Anda kelola. Itulah NEAR. Aplikasi Anda adalah akun (mis., twitter-app.yourname.near) dengan kode dan data sendiri. Validasi independen (node jaringan) menjaga data tersebut direplikasi dan tersedia. Ketika pengguna berinteraksi, jaringan mencapai finalitas—kesepakatan yang tidak dapat disengketakan tentang hasilnya—biasanya dalam ~1–2 detik.

Pemeriksaan jargon

• Validasi: node yang menjalankan perangkat lunak NEAR, mengeksekusi kontrak, dan berpartisipasi dalam konsensus.

• Finalitas: titik di mana perubahan dikunci dan tidak dapat dibalikkan.

Status Aplikasi: Dinasionalisasi dan Direplikasi

Di NEAR, data setiap aplikasi dikelompokkan ke akunnya—seperti skema database atau namespace yang didedikasikan.

• Status terisolasi: Hanya kode kontrak Anda yang dapat memodifikasi penyimpanan kunci nilai aplikasi Anda.

• Jejak audit: Setiap perubahan dicatat di rantai, menciptakan sejarah yang tidak dapat diubah, diverifikasi.

• Ketersediaan tinggi: Banyak validator menyimpan dan melayani status Anda. Jika beberapa mati, aplikasi Anda tetap dapat diakses.

• Konsistensi akhir yang cepat: Permintaan diproses, konsensus berjalan, dan dalam ~1–2 detik status baru final di seluruh jaringan.

Analogi: Bayangkan database cloud dengan replikasi tulis multi-region dan log audit bawaan yang tidak dapat dimatikan.

Logika Backend: Kontrak Pintar (Wasm)

Aturan bisnis Anda berada di dalam kontrak pintar—program kecil yang dikompilasi ke WebAssembly (Wasm) dan disimpan di bawah akun aplikasi Anda.

• Opsi bahasa: Rust adalah pilihan paling umum untuk kinerja dan keamanan. JavaScript/TypeScript juga digunakan melalui alat NEAR yang dikompilasi ke Wasm. [klarifikasi: konfirmasi apakah Anda ingin menekankan hanya Rust atau menyertakan near-sdk-js/TypeScript secara eksplisit.]

• Eksekusi terisolasi: Wasm efisien dan berjalan dalam lingkungan yang aman, deterministik pada validator.

• Batas yang jelas: Setiap kontrak mengelola statusnya sendiri dan mengekspos fungsi yang dipanggil klien.

Pemeriksaan jargon

• Kontrak pintar: kode backend yang berjalan di blockchain.

• WebAssembly (Wasm): format biner untuk eksekusi cepat, portabel.

Identitas dan Otorisasi: Kriptografi Secara Default

Daripada kata sandi, NEAR menggunakan akun dan tanda tangan digital.

• Transaksi: Setiap tulisan (perubahan status) adalah transaksi yang ditandatangani dari akun NEAR.

• Siapa yang memanggil saya?: Dalam kontrak, predecessor_account_id memberi tahu Anda akun mana yang memicu fungsi—seperti membaca pengguna dari token yang diverifikasi, tetapi didukung oleh kriptografi.

• Kontrol akses: Bangun pemeriksaan seperti “hanya akun ini yang dapat menghapus tweetnya” menggunakan ID akun pemanggil.

Analogi: Seperti JWT tanpa server login—identitas tertanam dalam platform.

Contoh Sederhana Gaya Twitter (Konseptual)

Misalkan Anda memodelkan Tweet { id, author, text, timestamp, likes }.

• Metode tulisan (mengubah status):

  • post_tweet(text): membuat tweet, author = predecessor_account_id.

  • like_tweet(id): menambahkan hitungan suka.

  • delete_tweet(id): hanya penulis tweet yang dapat menghapus.

• Metode baca (tampilan):

  • get_tweet_by_id(id)

  • get_all_tweets(from, limit)

  • get_tweets_by_author(author, from, limit)

Dari segi desain, pikirkan “pola akses indeks sederhana.” Kueri ad-hoc kompleks (mis., join) tidak ada di kontrak, jadi Anda merencanakan struktur data dan iterator Anda dengan itu dalam pikiran.

Bagaimana Klien Memanggil Kontrak Anda

Ada dua jenis panggilan, mencerminkan REST:

1. Panggilan mengubah status (seperti POST/PUT/DELETE)

   • Dikirim sebagai transaksi: termasuk receiver_id (kontrak Anda), method_name, args (JSON), gas (anggaran biaya), deposit opsional deposit, dan tanda tangan dari akun pemanggil.

   • Alat: NEAR CLI untuk skrip/operasi; near-api-js untuk frontend web dan mobile (dompet menangani penandatanganan).

2. Panggilan tampilan (seperti GET)