Clients and resources should be cached
See original GitHub issueWhen creating a vanilla client like session = boto3.Session(); s3 = session.client("s3")
, the client returned is not cached. I can’t see any reason why this client would be different between different calls, and the time to create a client can be quite long. Especially given that it’s generally better to pass a session around than the clients directly, it’d be nice if the client was cached on first load.
It wouldn’t use caching if credentials or a Config
object were passed, and it could maybe even have a single cache entry per service. Maybe it could be better solved with more caching in botocore.
It’s accomplishable today with the standard library’s functools
, though with a “developer beware” label.
import functools
import boto3
boto3.Session.client = functools.cache(boto3.Session.client)
boto3.Session.resource = functools.cache(boto3.Session.resource)
Issue Analytics
- State:
- Created 2 years ago
- Reactions:5
- Comments:7 (1 by maintainers)
Top Results From Across the Web
Ben Kehoe on Twitter: "boto3 doesn't cache clients and ...
boto3 doesn't cache clients and resources, either on Sessions or using the module-level functions (which just delegate to a default Session) ...
Read more >Web resource caching: Client-side - A Java geek
Web resource caching can happen in two different places: client-side - on the browser and server-side. This post is dedicated to the former; ......
Read more >What is Caching and How it Works - AWS
A cache is a high-speed data storage layer which stores a subset of data, typically transient in nature, so that future requests for...
Read more >Server-Side Caching vs. Client-Side Caching - Edgemesh
When it comes to answering the question — “I want to cache my website, what type of caching should I use?”The answer involves...
Read more >HTTP caching - MDN Web Docs
The shared cache is located between the client and the server and can store ... But if the server determines the requested resource...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Yeah read your article couple weeks ago and I didn’t realize I was talking to you. What you explain is pretty clean and I do understand what I need to do now 😃
@mbelang The session itself represents configuration and credentials. It doesn’t need caching internal to boto3, but it’s intended to be passed around in your code wherever clients/resources are needed (and are intended to use the same config/credentials), i.e., “cached” in your code. The refreshable credentials for web identity, for example, are refreshed by the session for any client created on the session. I wrote an explainer on why to use sessions. For example, when you create a library that makes AWS API calls, it should take an optional session as input (creating one itself using
boto3.Session()
if none is provided), and then get the appropriate client from the session. This pattern can lead to clients being created on the session multiple times in different places, which is why client caching would be beneficial.