在过去的4-5年里，我尝试了大量的Solana应用架构，我觉得是时候把我的发现写下来。从最简单的开始，逐渐增加复杂性。接下来是：Solana应用架构，一个主题。

2) 让我们从简单模式开始。这可能是你第一个 Solana 应用的样子。一个简单的 React 前端，建立与 RPC 的连接。无需 API 服务器。RPC 就是你的服务器。在早期，这些充满了 getAccountInfos、自定义交易构建逻辑等。 后来，当性能受到影响时，你会添加缓存和批处理层。引入 getMultipleAccounts。也许你还会添加 websocket 订阅 + 轮询来实时更新 UI。 这种架构使得原型制作极其快速。几乎没有 DevOps。服务器成本微乎其微（只需在 vercel 上部署等）。不过，它有一些主要缺陷。

3) 你遇到的第一个问题是复杂查询。在这种架构中，你所拥有的只是普通的 Solana RPC。这意味着你需要将 Solana 视为一个有态度问题的 NoSQL 数据库。点查询没有问题。你甚至可以通过 PDA 创造性地遍历你的程序数据，就像它是一个图形数据库一样。 但是一旦你需要进行第一次 gPA，你就会感到极大的痛苦。接口一点也不人性化。如果你有任何动态长度的数据，它根本无法使用。根据你的 RPC 提供商，它可能会慢得令人难以置信。 即使没有 gPA，这种方法通常也比典型的 web2 应用程序（具有服务器端渲染和正常数据库）慢得多。

4) 你遇到的第二个问题是交易构建逻辑的可移植性。在这种设置下，构建交易的所有逻辑要么在你的前端代码中，要么在你的代码导入的库中。在(a)的情况下，任何想要在你的前端之外构建交易的人都会面临极大的痛苦（包括你自己，当你不可避免地需要更多应用时）。在(b)的情况下，任何对交易构建逻辑的更改都需要库的发布，所有人更新他们的包，然后进行UI更新。 大量依赖Anchor工具，如账户解析，可以最小化需要移植的逻辑量——但问题依然存在。这剥夺了你的灵活性，并使得在确保所有版本的TX构建逻辑继续正常运行的同时，难以更改智能合约端点。

5) 你遇到的第三个问题是，用户界面通常在提交交易时表现不佳，尤其是在重试逻辑方面。用户可能会离开页面，交易停止重试。大量交易往往难以成功完成。从远处调试为什么交易没有成功是很困难的。

最后一个问题是，你并不是唯一拥有这种架构的人。RPC 是有价值的，你基本上必须在前端暴露你的 RPC URL。现在，你不得不进入一场猫鼠游戏，以确保没有人窃取你的 RPC 并提高你的成本。

7) 那接下来是什么？通常即使你没有解决交易可移植性的问题，你最终也需要处理列表查询。gPA 糟透了，我们都知道这一点。所以你可以构建一个混合架构。 在这个架构中，你保留快速原型的能力，但将那些丑陋且困难的查询推送到 API 中。一个很好的具体例子是治理——你有提案被创建，并且它们有一组标签（"经济"、"技术"等）。gPA 无法按标签过滤。

8) 这种架构并没有解决交易的可移植性，或者人们拔掉你的RPC。但在规模化时，你至少可以解决慢/不可能的gPA问题。 它确实引入了一个新问题——索引器。稍后会详细讨论。

9) 最后，你拥有我所称之为 "企业级" Solana 堆栈。你不再将 Solana 视为 NoSQL 数据库。相反，你将其视为事件总线。前端对 Solana 的数据模型一无所知。服务器构建交易并将其传递给 UI 进行签名，然后将其发送到 Solana 本身。它将此视为一个事件，并等待其传播回索引器，这将更改基础数据。 这种设置具有很好的交易可移植性 - 任何人都可以使用干净的参数访问你的 API，并获取交易/指令。 这使得 UI 非常灵敏 - 就 UI 而言，这基本上是 web2。你可以充分利用 SSR。 RPC 被抽象化 - 没有人可以窃取你的积分。 但这种设置也有其问题。

10) 你首先会遇到的问题是索引器的痛苦。虽然在过去几年中（多亏了Triton、Helius和StreamingFast团队）这一问题有所缓解，但我仍然经常用扳手打我们的索引器。你会错过消息。当你错过一条消息时，你的用户界面会进入一种奇怪的状态（例如：我给你发送了一个NFT，在链上你收到了它，但我的数据库显示我仍然拥有它）。这些类型的问题让人感到无比烦躁。是你的错吗？是你的数据提供者的问题吗？谁知道呢！你的一下午就这样过去了。

11) 你将遇到的下一个问题是时机。当你直接使用 RPC 进行所有操作时，他们允许你传递承诺并处理最新数据。使用索引器时，这一切都是手动的。这意味着当你构建交易时，你可能是基于过时的数据来构建它们。你返回的交易注定会失败。 你可以通过使用提供极快数据的数据提供者来解决过时数据的问题（例如 Helius 激光流）。但这时你需要手动处理重组。也就是说，如果该交易实际上没有通过，你索引的数据需要被取消索引。这真是个噩梦。

12) 你可以通过仅使用来自RPC的数据构建交易来“绕过”时序问题，并仅使用你的索引数据来供给UI。但这样，用户仍然会面临UI与链之间潜在不一致的问题。也就是说，前端说我拥有这个NFT并可以转移它，然后后端却对我大喊说我不能。

13) 你在这种设置中遇到的最后一个问题是成本，如果我们要夸张一点，可以称之为“去中心化的死亡”。web3 的梦想是无需部署大量的集中式服务器。现在你已经部署了足够的基础设施，可以让你在 web2 公司获得首席架构师的职位。这需要花费金钱。这需要花费时间。而且这一切都是非常集中化的。如果与您的协议交互的最佳方式是通过 web2 API，那么它的去中心化程度有多高？而且在 solana 上大约有 72 名开发者知道如何在没有该 API 的情况下与之交互。

14) 最终，我不会在去中心化的问题上死磕。对用户最好的选择往往是最佳选择。"企业"设置导致快速、现代的网络应用程序和清晰的关注点分离。缺点是，它增加了运维成本，使你变得不那么灵活。我建议大多数初创公司采用直接到RPC的方法，除非你正在构建一些明确需要快速或具有复杂查询语义的东西。市场时间是关键。你总是可以稍后雇佣一名中级工程师，把他们扔进索引地牢。

15) 财务。如果你们中有人找到更好的设置，请告诉我。这些都是我尝试过的东西。最近我很享受玩弄企业设置。