Thread safety and pooling best practices

[programcsharp]

It's not covered in the docs, but I believe the client is thread safe as it uses HttpClient under the covers for everything and that's thread safe.

Can you confirm that the client is indeed thread safe?

If so, I'd recommend adding a "best practices" section to the docs. All of the examples show newing up a client every time. That ends up doing expensive init and dns lookups every time. Reusing a single client (both the base PineconeClient and the IndexClient for an individual index) avoids that several second init.

I'm using something like this:

public class PineconeService
{
    static readonly ConcurrentDictionary<string, IndexClient> _indexClients = new();
    static readonly string PineconeToken = ConfigurationManager.AppSettings["PineconeToken"];
    
    static readonly Lazy<PineconeClient> _client = new(() => new PineconeClient(PineconeToken));
    
    public static PineconeClient Client => _client.Value;
    
    public static IndexClient GetIndexClient(string indexName)
    {
        return _indexClients.GetOrAdd(indexName, name => Client.Index(name: name));
    }
    
    public static void ClearIndexCache() => _indexClients.Clear();
}

[Swimburger]

Yes, it is thread safe. You're right about the samples not being optimal, but they're optimized for simplicity in this context. Would you expect this optimization to live within the SDK, or a best practices section as you suggest?

[programcsharp]

I could go either way on that. If there's a way to make SDK use Just Work, that's the best -- I like to call it the pit of success. Perhaps an internal cache of the lookups .Index does. Or a higher level singleton that's the recommended way to access, while leaving the lower level primitives available.

The easy win is to provide a best practice wrapper in the docs -- start from mine if you like. Then think about rolling it into the SDK at some point, once you come up with an API shape you like.