1) За последние 4-5 лет я экспериментировал с множеством архитектур приложений на Solana, и я понял, что пришло время изложить свои выводы. Начну с наименее сложного и постепенно добавлю больше сложности. Итак, вот: Архитектура приложений на Solana, тред.

2) Давайте начнем с простого режима. Вероятно, именно так выглядит ваше первое приложение на Solana. Простой фронтенд на React, устанавливающий соединение с RPC. Нет необходимости в API-сервере. RPC — это ваш сервер. В первые дни они были заполнены getAccountInfos, индивидуальной логикой построения транзакций и т.д. Позже, когда производительность начинает страдать, вы добавляете уровни кэширования и пакетирования. Вводите getMultipleAccounts. Возможно, вы также добавляете подписки по вебсокетам + опрос для обновления интерфейса в реальном времени. Эта архитектура позволяет очень быстро прототипировать. Практически ноль DevOps. Небольшие затраты на сервер (просто разверните на Vercel и т.д.). Однако у нее есть несколько серьезных недостатков.

3) Первая проблема, с которой вы столкнетесь, — это сложные запросы. В этой архитектуре у вас есть только стандартный Solana RPC. Это означает, что вам нужно рассматривать Solana так, как его представляет RPC — как NoSQL базу данных с проблемами. Точечные запросы не представляют проблемы. Вы даже можете проявить креативность с помощью PDA, чтобы обойти ваши данные программы, как если бы это была графовая база данных. Но как только вам нужно будет сделать ваш первый gPA, вы столкнетесь с максимальной болью. Интерфейс совсем не эргономичный. Если у вас есть данные переменной длины, их нельзя использовать вообще. В зависимости от вашего провайдера RPC, это может быть невероятно медленно. Даже без gPA этот подход, как правило, значительно медленнее, чем ваше типичное веб-приложение web2 с рендерингом на стороне сервера и обычной базой данных.

4) Вторая проблема, с которой вы сталкиваетесь, — это портативность логики построения транзакций. С этой настройкой вся логика для построения транзакций либо (a) находится в вашем фронтенд-коде, либо (b) в библиотеках, которые импортирует ваш код. В случае (a) любой, кто хочет построить транзакции вне вашего фронтенда, столкнется с максимальными трудностями (это касается и вас, когда вам неизбежно понадобится больше приложений). В случае (b) любые изменения в логике построения транзакций требуют публикации библиотек, обновления всех пакетов и затем обновления пользовательского интерфейса. Сильная зависимость от инструментов Anchor, таких как разрешение аккаунтов, может минимизировать количество логики, которую нужно переносить, — но проблема остается. Это лишает вас гибкости и затрудняет изменение конечных точек смарт-контрактов, при этом обеспечивая функционирование всех версий вашей логики построения TX.

5) Третья проблема, с которой вы сталкиваетесь, заключается в том, что пользовательские интерфейсы, как правило, плохо справляются с отправкой транзакций, особенно с логикой повторных попыток. Пользователь может покинуть страницу, и TX перестает пытаться повторно. Большие объемы транзакций, как правило, испытывают трудности с завершением. Сложно отладить издалека, почему транзакции не завершаются.

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

7) Итак, что дальше? Обычно, даже если вы не решаете проблему портативности транзакций, вам все равно нужно будет решить вопросы с запросами списка. gPA отстой, и мы все это знаем. Поэтому вы можете построить гибридную архитектуру. В этой архитектуре вы сохраняете возможность быстро прототипировать, но сложные и неудобные запросы отправляете в API. Хороший конкретный пример этого — управление: у вас есть создаваемые предложения, которые имеют набор тегов ("Экономический", "Технический" и т.д.). gPA не может фильтровать по тегу.

8) Эта архитектура не решила проблему портативности транзакций или того, что люди могут отключить ваш RPC. Но на большом масштабе вы, по крайней мере, можете решить проблему медленных/невозможных gPAs. Это вводит новую проблему — индексаторы. Подробнее об этом позже.

9) Наконец, у вас есть то, что я бы назвал "корпоративным" стеком Solana. Вы больше не рассматриваете Solana как NoSQL базу данных. Вместо этого вы рассматриваете ее как шину событий. Фронтенд ничего не знает о модели данных Solana. Сервер создает транзакции и передает их интерфейсу для подписи, а затем отправляет их непосредственно в Solana. Он рассматривает это как событие и ждет, пока оно не вернется к индексаторам, которые изменят базовые данные. Эта настройка обеспечивает отличную портативность транзакций - любой может обратиться к вашему API с чистыми параметрами и получить обратно транзакции/инструкции. Это создает чрезвычайно отзывчивый интерфейс -- с точки зрения интерфейса, это в основном web2. Вы можете в полной мере воспользоваться SSR. RPC абстрагирован -- никто не может украсть ваши кредиты. Но у этой настройки есть свои проблемы.

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

11) Следующая проблема, с которой вы столкнетесь, — это время. Когда вы напрямую используете RPC для всего, они позволяют вам передавать обязательства и работать с последними данными. С индексатором это все вручную. Это означает, что, когда вы создаете транзакции, вы можете создавать их на основе устаревших данных. Вы возвращаете транзакцию, которая обречена на провал. Вы можете решить проблему устаревших данных, используя поставщиков данных, которые предоставляют вам чрезвычайно быстрые данные (например, Helius laser stream). Но тогда вам нужно вручную справляться с реорганизациями. То есть данные, которые вы индексируете, нужно будет удалить из индекса, если эта транзакция на самом деле не прошла. Это настоящий кошмар.

12) Вы можете "взломать" проблемы с таймингом, всегда создавая транзакции, используя данные из RPC, и используя только ваши индексированные данные для подачи в интерфейс. Но тогда у пользователей все равно будут проблемы с потенциальными несоответствиями между интерфейсом и цепочкой. То есть, интерфейс говорит, что я владею этим NFT и могу его передать, а затем бэкенд кричит на меня и говорит, что я не могу.

13) Последняя проблема, с которой вы сталкиваетесь с этой настройкой, — это стоимость, и если говорить мелодраматично, то "смерть децентрализации". Мечта web3 заключалась в том, чтобы не развертывать кучу централизованных серверов. Теперь вы развернули достаточно инфраструктуры, чтобы получить работу главного архитектора в компании web2. Это стоит денег. Это требует времени. И это все очень централизовано. Насколько децентрализован ваш протокол, если лучший способ взаимодействовать с ним — это через веб2 API? И есть около 72 разработчиков на Solana, которые знают, как взаимодействовать с ним без этого API.

14) В конечном итоге я не собираюсь умирать на холмах вокруг децентрализации. То, что лучше для пользователей, как правило, является лучшим выбором. Настройка "предприятия" приводит к быстрым, современным веб-приложениям и четкому разделению обязанностей. С другой стороны, это увеличивает затраты на devops и делает вас менее гибкими. Я рекомендую большинству стартапов начинать с метода прямого доступа к rpc, если вы не создаете что-то, что явно должно быть быстрым или иметь сложную семантику запросов. Время выхода на рынок имеет ключевое значение. Вы всегда можете нанять инженера среднего уровня позже и отправить его в подземелье индексирования.

15) Фин. Если кто-то из вас нашел лучшую настройку, дайте знать. Это все, что я пробовал. Мне довольно нравится возиться с корпоративной настройкой в последнее время.