Is the Stripe Client via async-stripe thread safe? Should I use 1 per request, connection, thread/worker, or server?

[WarrenN1]

I am setting up my stripe web server backend. My questions is as follows:

1. Should a Stripe Client be used per 1 request, 1 connection, 1 thread, or 1 web server?
   I know for example a DB pool you have 1 Pool per web server, but under the hood you have N clients where N is the number of connections if each client is asynchronous.
   I know for a DB pool with synchronous clients for an async web server you will usually have M clients where M is the number of concurrent requests you want outgoing at once and a queue built into the pool to store buffered requests.

My question is for the stripe client, should I have 1 client per request (ie. initializing a Stripe client and then building the checkout), 1 client per connection (ie. each connection has their own Stripe Client), 1 per thread (each worker on the web server has a Stripe client that they use to generate checkout links), 1 per web server (this implies the stripe client is thread safe).

Ideally I would hope it is 1 per web server so I can throw it behind a rust rocket fairing, but I wanted to check before I began development. Any guidance you could provide would be deeply appreciated.

[arlyon]

If you'd like multiple clients at once, you can just clone it.

[WarrenN1]

@arlyon Thank you so much for your help. It is deeply appreciated.

However, can you please explain a bit more than just how to use it as I would like to understand how it works rather than simply taking the above answer as a fix and moving forward? What exactly is the Stripe Client in async-stripe? Is it thread safe etc? I am open to a zoom call or other mediums if typing the answer is too cumbersome. I would just like to have a better understanding of the technology I am using before I use it.

I am trying to understand the best practice for an asynchronous rust rocket web server with 5 workers so I use the library as intended.

[seanpianka]

See https://github.com/arlyon/async-stripe/blob/master/src/client/base/tokio.rs#L75-L187 for more information. There is no use of unsafe and so Rust will guarantee thread safety.

[arlyon]

Yep, we don't allow any unsafe code at all, so if the compiler lets you do it then you can.

https://github.com/arlyon/async-stripe/blob/master/src/lib.rs#L57

Since rust is thread safe at the type level, then so is this library. Specifically:

• all the clients are thread safe, with respect to the Send + Sync bounds of a normal rust async application
• if you need to make a new client, for a new thread, you can just clone it and move it to that task
• the same client can make multiple requests concurrently (using, for example, tokio::join), since requests do not require mutable access to the client to execute.

For the purposes of rocket, you could for example create a State. Notice in the docs that the compiler guarantees its thread-safe-ness:

Because Rocket automatically parallelizes your application, handlers can concurrently access managed state. As a result, managed state must be thread-safe. Thanks to Rust, this condition is checked at compile-time by ensuring that the type of values you store in managed state implement Send + Sync.

If the client was not Send or Sync, the code will not compile.

I am not familiar with rocket but there is nothing stopping you from creating a &'static Client using something like a LazyLock and just passing that reference around.