1) Selama 4-5 tahun terakhir saya telah bereksperimen dengan banyak arsitektur aplikasi Solana, dan saya pikir sudah waktunya saya menulis temuannya. Dimulai dengan yang paling tidak rumit dan menambahkan kompleksitas yang semakin besar. Jadi inilah dia: Arsitektur Aplikasi Solana, utas.

2) Mari kita mulai dengan mode mudah. Ini mungkin seperti aplikasi Solana pertama Anda. Frontend reaksi sederhana, membuat koneksi ke RPC. Tidak perlu server api. RPC adalah server Anda. Pada hari-hari awal, ini dipenuhi dengan getAccountInfos, logika konstruksi tx yang dipesan lebih dahulu, dll. Nantinya, ketika kinerja akhirnya menderita, Anda menambahkan lapisan caching dan batching. Masukkan getMultipleAccounts. Mungkin Anda juga menambahkan langganan websocket + polling untuk memperbarui UI secara langsung. Arsitektur ini membuat pembuatan prototipe sangat cepat. Hampir tidak ada devops. Biaya server yang dapat diabaikan (cukup terapkan di vercel, dll). Namun, ada beberapa kekurangan utama.

3) Masalah pertama yang Anda temui adalah kueri yang rumit. Dalam arsitektur ini, yang Anda miliki hanyalah Solana RPC vanilla. Itu berarti Anda perlu memperlakukan Solana dengan cara RPC mengeksposnya -- sebagai db NoSQL dengan masalah sikap. Kueri titik tidak masalah. Anda bahkan bisa menjadi sangat kreatif dengan PDA untuk melintasi data program Anda seperti database grafik. Tetapi segera setelah Anda perlu melakukan gPA pertama Anda, Anda akan mengalami rasa sakit maksimal. Antarmukanya sama sekali tidak ergonomis. Jika Anda memiliki data yang dipanjangkan secara dinamis, itu tidak dapat digunakan sama sekali. Tergantung pada penyedia RPC Anda, itu bisa sangat lambat. Bahkan tanpa gPA, pendekatan ini cenderung jauh lebih lambat daripada aplikasi web2 biasa Anda dengan rendering sisi server dan database normal.

4) Masalah kedua yang Anda temui adalah portabilitas logika konstruksi transaksi. Dengan penyiapan ini, semua logika untuk membuat transaksi ada (a) dalam kode frontend Anda atau (b) di pustaka yang diimpor kode Anda. Dalam kasus (a), siapa pun yang ingin membuat transaksi di luar frontend Anda akan mengalami rasa sakit maksimal (ini termasuk Anda, ketika Anda pasti membutuhkan lebih banyak aplikasi). Dalam kasus (b) setiap perubahan pada logika konstruksi transaksi memerlukan publikasi pustaka, semua orang memperbarui paket mereka, lalu pembaruan UI. Sangat bersandar pada alat Anchor seperti resolusi akun dapat meminimalkan jumlah logika yang perlu di-porting -- tetapi masalahnya tetap ada. Ini merampas kelincahan Anda, dan menyulitkan untuk mengubah titik akhir kontrak pintar sambil memastikan semua versi logika bangunan TX Anda terus berfungsi.

5) Masalah ketiga yang Anda hadapi adalah fakta bahwa UI umumnya buruk dalam mengirimkan transaksi, terutama dengan logika coba lagi. Pengguna dapat menavigasi keluar dari halaman, TX berhenti mencoba lagi. Sejumlah besar transaksi cenderung kesulitan untuk mendarat. Sulit untuk men-debug dari jauh mengapa segala sesuatunya tidak mendarat.

6) Masalah terakhir di sini adalah Anda bukan satu-satunya dengan arsitektur ini. RPC sangat berharga, dan pada dasarnya Anda harus mengekspos URL RPC Anda di frontend Anda. Sekarang, Anda bisa berakhir dalam permainan kucing dan tikus untuk memastikan tidak ada yang mencuri RPC Anda dan menaikkan biaya Anda.

7) Jadi apa selanjutnya? Biasanya bahkan jika Anda tidak menangani portabilitas tx, Anda akhirnya perlu menangani kueri daftar. gPA menyebalkan, dan kita semua tahu itu. Jadi Anda dapat membangun arsitektur hybrid. Dalam arsitektur ini, Anda mempertahankan kemampuan untuk membuat prototipe dengan cepat, tetapi mendorong kueri yang sulit dan jelek ke dalam API. Contoh konkret yang bagus dari ini adalah tata kelola -- Anda memiliki proposal yang dibuat yang memiliki seperangkat tag di atasnya ("Ekonomi", "Teknis", dll). gPA tidak dapat melakukan pemfilteran berdasarkan tag.

8) Arsitektur ini belum memecahkan portabilitas transaksi, atau orang yang menarik RPC Anda. Tetapi dalam skala besar, Anda setidaknya dapat memecahkan masalah gPA yang lambat/mustahil. Ini memperkenalkan masalah baru - pengindeks. Lebih lanjut tentang ini nanti.

9) Akhirnya, Anda memiliki apa yang saya sebut tumpukan Solana "perusahaan". Anda tidak lagi memperlakukan Solana sebagai database NoSQL. Sebaliknya, Anda memperlakukannya seperti bus acara. Frontend tidak tahu apa-apa tentang model data Solana. Server membuat transaksi dan meneruskannya ke UI untuk ditandatangani, lalu mengirimkannya ke Solana itu sendiri. Ini memperlakukan ini sebagai peristiwa dan menunggunya untuk menyebar kembali ke pengindeks yang akan mengubah data yang mendasarinya. Pengaturan ini memiliki portabilitas transaksi yang hebat - siapa pun dapat menekan API Anda dengan parameter yang bersih dan mendapatkan kembali transaksi/instruksi. Itu membuat UI yang sangat tajam -- sejauh menyangkut UI, ini pada dasarnya adalah web2. Anda dapat memanfaatkan SSR sepenuhnya. RPC diabstraksikan -- tidak ada yang bisa mencuri kredit Anda. Tapi pengaturan ini memiliki masalah tersendiri

10) Masalah pertama yang akan Anda temui adalah nyeri pengindeks. Meskipun ini telah dikurangi dalam beberapa tahun terakhir (berkat tim Triton, Helius, dan StreamingFast), saya masih akhirnya mengalahkan pengindeks kami dengan kunci pas secara teratur. Anda akan melewatkan pesan. Saat Anda melewatkan pesan, UI Anda menjadi aneh (contoh: Saya mengirimi Anda NFT, secara berantai Anda menerimanya, database saya mengatakan saya masih memilikinya). Jenis masalah ini menjengkelkan untuk di-debug. Apakah itu salahmu? Apakah itu penyedia data Anda? Siapa tahu! Itu sore Anda.

11) Masalah berikutnya yang akan Anda temui adalah waktu. Saat Anda langsung menggunakan RPC untuk semuanya, mereka memungkinkan Anda meloloskan komitmen dan menangani data terbaru. Dengan pengindeks, ini semua manual. Ini berarti ketika Anda membuat transaksi, Anda dapat membangunnya berdasarkan data yang kedaluwarsa. Anda mengembalikan transaksi yang pasti gagal. Anda dapat memecahkan masalah data yang kedaluwarsa dengan menggunakan penyedia data yang memberi Anda data yang sangat cepat (misalnya aliran laser Helius). Tetapi kemudian Anda perlu menangani reorganisasi secara manual. IE, data yang Anda indeks perlu dibatalkan jika tx itu tidak benar-benar berakhir. Ini adalah mimpi buruk.

12) Anda dapat "meretas" masalah waktu dengan hanya membuat transaksi menggunakan data dari RPC, dan hanya menggunakan data yang diindeks untuk memberi makan UI. Namun, pengguna masih akan memiliki masalah dengan potensi inkonsistensi antara UI dan rantai. IE frontend mengatakan saya memiliki NFT ini dan dapat mentransfernya, lalu backend berteriak kepada saya dan mengatakan saya tidak bisa.

13) Masalah terakhir yang Anda hadapi dengan pengaturan ini adalah biaya, dan jika kita bersikap melodramatis "kematian desentralisasi." Impian web3 adalah tidak harus menyebarkan banyak server terpusat. Sekarang Anda telah menerapkan infra yang cukup untuk mendapatkan pekerjaan arsitek utama di toko web2. Butuh uang. Butuh waktu. Dan semuanya sangat terpusat. Seberapa terdesentralisasi protokol Anda jika cara terbaik untuk berinteraksi dengannya adalah melalui API web2? Dan ada seperti 72 pengembang di solana yang akan tahu cara berinteraksi dengannya tanpa API itu.

14) Pada akhirnya, saya tidak akan mati di bukit mana pun di sekitar desentralisasi. Apa yang terbaik untuk pengguna cenderung menjadi pilihan terbaik. Pengaturan "perusahaan" mengarah pada aplikasi web yang cepat dan modern serta pemisahan masalah yang bersih. Di sisi negatifnya, ini menambah biaya devops dan membuat Anda kurang gesit. Saya merekomendasikan sebagian besar startup memulai dengan metode direct-to-rpc kecuali Anda membangun sesuatu yang secara eksplisit harus cepat atau memiliki semantik kueri yang kompleks. Waktu ke pasar adalah kuncinya. Anda selalu dapat menyewa insinyur tingkat menengah nanti dan membuangnya ke ruang bawah tanah pengindeksan.

15) Sirip. Jika ada di antara Anda yang menemukan pengaturan yang lebih baik, lmk. Ini semua adalah hal yang telah saya coba. Saya cukup menikmati mengotak-atik pengaturan perusahaan akhir-akhir ini.