Consider using IHttpClientFactory internally for better HttpClient lifecycle management

[tcortega]

Currently, ClientFactory.GetClient() accepts an HttpClient instance as a parameter. This can lead to HttpClient lifetime issues when using dependency injection, as the IRpcClient may hold onto the HttpClient reference.

When registering IRpcClient as Singleton with a provided HttpClient, the HttpClient lives forever
When registering as Scoped/Transient, we lose connection pooling benefits

Consider accepting IHttpClientFactory instead of HttpClient, or provide an overload that accepts it. This would allow proper integration with .NET's dependency injection while maintaining optimal HttpClient lifecycle management.

https://learn.microsoft.com/en-us/dotnet/core/extensions/httpclient-factory

This would enable clean DI registration without worrying about HttpClient disposal.

[kingsznhone]

After conducting a survey, I’ve noticed several issues with using IHttpClientFactory in certain scenarios:

• While a singleton HTTP client can efficiently reuse TLS connections, IHttpClientFactory may release connection resources at any time, potentially causing significant overhead due to frequent connection re-establishment.
• It’s very difficult to apply rate limiting (e.g., IRateLimiter) effectively when using pooled clients. In high-frequency trading situations, a robust rate-limiting mechanism is critical to avoid hitting HTTP 429 errors from paid RPC nodes. Without it, you’d need to implement extensive retry logic around every HTTP 429 response.
• Dependency injection (DI) registration adds unnecessary complexity for simple console applications that only require a fast, clean RPC function for a specific purpose.

In my opinion, the SolanaRpcClient class should be implemented as a singleton service within the DI architecture application. It would maintain a persistent HttpClient internally and accept requests from various modules. All outgoing RPC calls would then be dispatched through a centralized, orderly queue with built-in rate limiting to ensure reliability and compliance with API usage limits.