Developer Best Practices
This article provides best practices for Web3 developers as it helps in writing code efficiently, maintainably, and securely.
Following best practices can reduce the number of errors and security vulnerabilities in your code and make it easier for other developers to understand and work with, saving time and resources. Adhering to best practices also improves the overall quality and reliability of the software, which helps build trust and reputation with users.
Overall, adhering to developer best practices is a key component in building high-quality software.
1. Send Requests Concurrently
Based on your needs for using blockchain nodes, you may think that requests need to be sent in a specific order for them to work correctly.
But that's not the case! Don't consider SolarPath as a single node or a group of nodes. Instead, think of it as an automated and scalable service that can handle concurrent request patterns.
You don't have to worry about overloading SolarPath by using large-scale concurrent requests. SolarPath is specifically designed to handle high-concurrency requests.
2. Avoid High Batch Cardinality
When using batch requests, it is recommended to limit the number of methods in a batch to 30 or fewer.
If you need to quickly obtain hundreds or thousands of responses, it is better to send multiple batch requests simultaneously instead of putting all requests in a single call.
Blockchain responses can be heavy, which means that certain requests sent to nodes, such as eth_getLogs, can have unlimited size or execution time.
By batching smaller sets of requests, you can minimize timeouts caused by unlimited response sizes and execution times, ensuring higher throughput.
For the introduction and use of batch requests, see the: Make Batch Requests.
3. Use Event Hook instead of Polling and Websockets
SolarPath recommends using Event Hook to replace long polling and websockets.
Event Hook can effectively address the issues of WebSocket disconnections and reconnects, providing stability. Developers can receive notifications from on-chain contract events, such as changes in ERC20/TRC20 token balances, with minimal coding effort.
Please refer to the operation steps: Event Hook
4. Send Requests over HTTPS, not Websockets
Although using WebSockets for all node requests may seem tempting as it is a newer technology, industry best practices for using WebSockets primarily focus on push-based notifications, such as using eth_subscribe and eth_unsubscribe event notifications in the case of EVM chains.
However, for standard JSON-RPC node requests, there are several reasons why HTTP is a better choice:
Silent failures: WebSockets clients involve handling various tricky edge cases and silent failure modes.
Load balancing: When making requests to distributed systems like SolarPath, a single HTTP request gets load balanced to the fastest server, whereas using WebSockets would involve sending JSON-RPC requests to a single node, introducing additional latency.
Retries: Most common request frameworks have built-in support for automatically retrying failed HTTP requests and can be easily configured. On the other hand, retrying failed requests in WebSockets often requires custom tracking based on JSON-RPC IDs.
HTTP status codes: When Web3 developers use WebSockets, they do not receive HTTP status codes in WebSocket responses, which can be useful for debugging or troubleshooting exceptional responses.
4. Avoid Large Request / Response Sizes
We recommend keeping the majority of your requests below 100 KB and avoiding response sizes exceeding 5 MB.
While we allow sending large requests (currently up to 2.5 MB) and receiving large responses (currently up to 50 MB), we strongly advise against such requests whenever possible. This is for several reasons:
Larger requests and responses are more likely to reach our size limits, resulting in failed API calls.
Heavy API calls are more prone to timeouts, failures during execution, and can make your service unstable.
Smaller API calls are easier to debug and identify any issues that may arise.
By making smaller API requests or responses, you will make your product more reliable, responsive, and spend less time debugging your program.
5. Use Compression
At SolarPath, many developers have raised concerns about slow response times being a significant obstacle to delivering a good Web3 user experience for their customers.
To provide users with a better product experience, we offer support for gzip compression for all responses larger than 1kb.
Gzip compression can reduce the file size sent over the streaming connection by up to 95%. However, the actual latency and bandwidth savings depend on the structure of the on-chain data, the speed of the client-server connection, and the size of the response.
In practice, we have found that the overall latency of typical JSON-RPC calls is reduced by approximately 75% when gzip compression is enabled.
To enable gzip compression, you simply need to append the field "Accept-Encoding: gzip" to the JSON-RPC request header. Here is an example:
This optimization can significantly improve the performance of your requests and enhance the overall user experience.
6. Protecting your API Keys
In some cases, you may want to embed the API key in a public location, such as a frontend app.
To prevent accidental exposure of the API key, you can set up whitelist domains, contract addresses, or IP addresses that are allowed to send requests in the SolarPath Dashboard.
Please refer to the operation steps: Secure your API Keys
Last updated