1) За останні 4-5 років я експериментував із великою кількістю архітектур застосунків Solana і вирішив, що настав час описати результати. Починаючи з найпростіших і поступово додаючи складності. Отже, ось так: Solana Application Architecture, тема.

2) Почнемо з легкого режиму. Ймовірно, саме так виглядає ваш перший додаток Solana. Простий інтерфейс react встановлює з'єднання з RPC. API сервер не потрібен. RPC — це ваш сервер. У перші роки вони були завалені getAccountInfos, спеціальною логікою побудови tx тощо. Пізніше, коли продуктивність погіршується, додаєш шари кешування та пакетування. Зустрічайте getMultipleAccounts. Можливо, ви також додаєте підписки на websocket + опитування для оновлення інтерфейсу в реальному часі. Ця архітектура забезпечує надзвичайно швидке прототипування. Практично немає DevOps. Незначні витрати на сервер (просто розгортайте на Vercel тощо). Втім, у нього є кілька серйозних недоліків.

3) Перша проблема, з якою ви стикаєтеся, — це складні запити. У цій архітектурі у вас є лише стандартна Solana RPC. Це означає, що потрібно ставитися до Solana так, як це показує RPC — як до NoSQL бази даних із проблемою ставлення. Запити до точок — не проблема. Ви навіть можете проявити дуже креативність із КПК, щоб обходити дані програми, ніби це графова база даних. Але щойно потрібно зробити перший середній бал, біль буде максимальним. Інтерфейс зовсім не ергономічний. Якщо у вас є будь-які дані динамічної довжини, їх взагалі не можна використовувати. Залежно від вашого провайдера RPC, це може бути неймовірно повільно. Навіть без gPA цей підхід зазвичай набагато повільніший, ніж типовий web2-додаток із серверним рендерингом і звичайною базою даних.

4) Друга проблема, з якою ви стикаєтеся, — це портативність логіки побудови транзакцій. У такій конфігурації вся логіка для побудови транзакцій знаходиться або (а) у вашому фронтенд-коді, або (б) у бібліотеках, які імпортує ваш код. У випадку (a), будь-хто, хто хоче будувати транзакції поза вашим фронтендом, отримає максимальний біль (це стосується і вас, коли вам неминуче потрібен додатковий додаток). У випадку (b) будь-які зміни в логіці побудови транзакцій вимагають публікації бібліотекою, оновлення пакетів усім і подальшого оновлення інтерфейсу. Сильна орієнтація на інструменти Anchor, як-от розв'язання акаунтів, може мінімізувати кількість логіки, яку потрібно переносити — але проблема залишається. Це позбавляє вас гнучкості і ускладнює зміну кінцевих точок смарт-контрактів, забезпечуючи при цьому роботу всіх версій логіки будівництва TX.

5) Третя проблема, з якою ви стикаєтеся, — це те, що інтерфейси загалом погано подачі транзакцій, особливо з логікою повторних спроб. Користувач може відійти від сторінки, TX припиняє повторні спроби. Великі обсяги транзакцій часто мають труднощі з отриманням. Здалеку важко налагодити, чому щось не виходить.

6) Остання проблема в тому, що ви не єдиний з такою архітектурою. RPC цінний, і вам фактично потрібно показати URL RPC у фронтенді. Тепер ви можете потрапити в гру в кішки-мишки, щоб переконатися, що ніхто не краде ваш RPC і не підвищує витрати.

7) Що далі? Зазвичай, навіть якщо ви не вирішуєте портативність tx, доводиться відповідати на запити до списку. gPA — це жахливо, і ми всі це знаємо. Тож можна створити гібридну архітектуру. У цій архітектурі ви зберігаєте можливість швидко прототипувати, але переносити складні запити в API. Гарний конкретний приклад — управління: створюються пропозиції з набір тегів («Економічний», «Технічний» тощо). gPA не може робити фільтр за тегом.

8) Ця архітектура не вирішила питання портативності транзакцій або вилучення RPC. Але в масштабі ви принаймні можете вирішити проблему повільних/неможливих середніх балів. Це додає нову проблему — індексери. Більше про це пізніше.

9) Нарешті, у вас є те, що я б назвав «корпоративною» стеком Solana. Ви більше не розглядаєте Solana як NoSQL базу даних. Натомість ви ставитеся до неї як до автобуса для заходів. Фронтенд нічого не знає про модель даних Solana. Сервер створює транзакції і передає їх інтерфейсу для підписання, а потім надсилає безпосередньо Solana. Він розглядає це як подію і чекає, поки вона повернеться до індексаторів, які змінять базові дані. Ця конфігурація має чудову портативність транзакцій — будь-хто може запропонувати ваш API чистими параметрами і отримати назад транзакції/інструкції. Це створює надзвичайно швидкий інтерфейс — з точки зору інтерфейсу, це фактично web2. Ви можете повністю скористатися SSR. RPC абстрагований — ніхто не може вкрасти ваші кредити. Але ця система має свої проблеми

10) Перша проблема, з якою ви зіткнетеся, — це біль індексера. Хоча за останні кілька років це було полегшено (завдяки командам Triton, Helius і StreamingFast), я все одно регулярно обганяю наш індексатор з гайковим ключем. Ви будете пропускати повідомлення. Коли ви пропускаєте повідомлення, ваш інтерфейс переходить у дивний стан (наприклад: я надіслав вам NFT, у ланцюжку ви його отримали, у моїй базі даних пише, що він досі є моїм власником). Такі проблеми дуже дратують для налагодження. Це твоя провина? Це ваш провайдер даних? Хто знає! Ось і твій післяобідній час.

11) Наступна проблема, з якою ви зіткнетеся, — це таймінг. Коли ви безпосередньо використовуєте RPC для всього, вони дозволяють приймати зобов'язання та працювати з останніми даними. З індексатором це все відбувається вручну. Це означає, що при створенні транзакцій ви можете будувати їх на основі застарілих даних. Ви повертаєте транзакцію, яка приречена на провал. Ви можете вирішити проблему застарілих даних, використовуючи провайдери даних, які надають надзвичайно швидкі дані (наприклад, лазерний потік Helius). Але тоді доведеться самостійно займатися реорганізаціями. Тобто, дані, які ви індексуєте, мають бути не індексовані, якщо ця перевірка фактично не пройшла. Це справжній кошмар.

12) Ви можете обійти проблеми з часом, будуючи транзакції лише з даних з RPC, а індексовані дані — лише для подачі інтерфейсу. Але тоді користувачі все одно матимуть проблеми з потенційними невідповідностями між інтерфейсом і ланцюгом. IE frontend каже, що я володію цим NFT і можу його перенести, а бекенд кричить на мене і каже, що я не можу.

13) Остання проблема, з якою ви стикаєтеся в цій системі — це вартість, а якщо ми драматизуємо — «смерть децентралізації». Мрією web3 було не розгортати купу централізованих серверів. Тепер ви розгорнули достатньо інфраструктури, щоб отримати посаду провідного архітектора в web2-сервісі. Це коштує грошей. Це коштує часу. І все дуже централізовано. Наскільки децентралізований ваш протокол, якщо найкращий спосіб взаємодії з ним — через web2 API? І на Solana є близько 72 розробників, які знають, як з нею взаємодіяти без цього API.

14) Зрештою, я не збираюся помирати на жодних пагорбах через децентралізацію. Те, що найкраще для користувачів, зазвичай є найкращим вибором. «Корпоративна» конфігурація веде до швидких, сучасних вебдодатків і чіткого розділення питань. З іншого боку, це додає вартість devops і робить вас менш спритними. Рекомендую більшості стартапів починати з методу прямого підключення до rpc, якщо ви не створюєте щось, що має бути швидким або має складну семантику запитів. Час виходу на ринок — ключовий. Ви завжди можете найняти інженера середнього рівня пізніше і кинути його в індексоване підземелля.

15) Фін. Якщо хтось із вас знайшов кращу конфігурацію, дайте знати. Це все, що я пробував. Останнім часом мені дуже подобається експериментувати з корпоративною конфігурацією.