Web3 开发者最佳实践
本文提供给Web3开发者的最佳实践，因为这有助于高效、可维护和安全的方式编写代码。
遵循最佳实践可以减少代码中错误和安全漏洞的数量，并使其他开发人员更容易理解和使用，从而节省时间和资源。坚持最佳实践还可以提高软件的整体质量和可靠性，这有助于与用户建立信任和信誉。
总体而言，遵循开发者最佳实践是构建高质量软件的关键部分。
1. 并发发送请求
根据您使用区块链节点的诉求，您可能希望请求需要按顺序发送才能正常运行。
事实并非如此！ 不要将 SolarPath 视为单个节点或一组节点，应将其视为可以处理并发请求模式的自动化、可扩展服务。
您无需担心使用大规模并发请求使 SolarPath 过载。SolarPath 专为处理高并发请求而构建。
2. 避免高批量请求
当使用批量请求时，建议将批量请求方法数量限制在 30 个以下。
如果您需要快速获得数百或上千个响应，请同时发送更多批处理请求，而不是将所有请求放在一次调用中。 区块链响应往往很重，这意味着发送到节点的某些请求的响应（如 eth_getLogs 可以具有无限大小或执行时间。
通过批处理较小的请求集，您可以最大限度地减少由于无限制响应大小和无限执行时间而导致的超时，并保证更高的吞吐量。
批量请求的介绍和使用，参见: 批量请求
3. 使用 Event Hook 代替轮询和 Websockets
SolarPath 建议使用 Event Hook 来替代轮询请求和 Websockets。
Event Hook 可有效解决 Websocket 断连、重连等不稳定问题。开发人员可以通过少量的编码就能接收链上合约事件发出的通知，如账户ERC20/TRC20余额变动等。
使用EventHook操作步骤参见: 订阅和事件
4. 使用 HTTPS 发送请求，而不是 Websockets
尽管对所有节点请求使用 WebSockets 可能很诱人，因为它是一项较新的技术，但使用 WebSockets 的行业最佳实践主要用于基于推送的通知。如在 EVM 链的情况下，用 eth_subscribe 和 eth_unsubscribe 事件通知。
但出于以下几个原因，HTTPs 是标准 JSON-RPC 节点请求的更好选择：
静默失败：WebSockets 客户端处理有许多棘手的特殊情况和静默失败模式。
负载均衡：当向 SolarPath 等分布式系统发出请求时，单个 HTTPs 请求会负载到最快的服务器，而使用 WebSockets 时，您会通过仅向单个节点发送 JSON-RPC 请求，这样做，会招致额外的延迟。
重试机制：在大多数常见的请求框架中，自动支持重试失败的 HTTP 请求，并且可以轻松配置。相反，在 WebSockets 中失败重试的请求通常需要自定义基于 JSON-RPC ID 进行跟踪。
HTTP 状态代码：当 Web3 开发人员使用 WebSockets 时，他们不会在 WebSockets 响应中收到 HTTP 状态代码，这对于调试或排查异常响应很有用。
4. 避免大请求 / 响应
我们建议将绝大多数请求保持在 100 KB 以下，并避免响应大小超过 5 MB。
虽然我们允许发送大型请求（目前最多 2.5 MB）和接收大型响应（目前最多 50 MB），但我们强烈建议尽可能避免这样的请求。 这是出于以下几个原因：
较大的请求和响应更有可能达到我们的大小限制，这将导致您的 API 调用失败。
繁重的 API 调用更有可能超时、在运行过程中失败并导致您的服务变得不稳定。
较小的 API 调用更易于调试和识别出现的问题。
通过调用较小的 API 请求或响应，将使您的产品变得更加可靠、响应迅速，并且也会花费更少的时间来调试您的程序。
5. 使用gzip压缩
在 SolarPath，许多开发人员都提出响应时间慢是阻碍其客户提供良好 Web3 用户体验的主要障碍。
为了给用户提供更好的产品体验，我们为开发者提供对所有大于1kb的响应进行gzip压缩的支持。 gzip 压缩可将通过流式连接发送的文件大小减少多达 95%。 然而，实际的延迟和带宽节省取决于链上数据的结构、客户端和服务器的连接速度以及响应的大小。
在实践中，我们发现典型的 JSON-RPC 调用的总延迟大约减少了 75%。
要启用 gzip 压缩，您只需将字段“Accept-Encoding: gzip”附加到 JSON-RPC 请求标头。 如下：
6. 保护您的 API 密钥
在某些情况下，您可能希望将 API 密钥嵌入某个公共位置，如前端应用程序。
为避免意外泄露 API 密钥，您可以在 SolarPath Dashboard 中设置白名单域、合约地址或 IP 地址能够发送请求。
关于如何保护API Keys请参见: 安全访问措施
最后更新于