This comment has been minimized.

Does this mean, "google-api-python-client" would be replaced by something else ?
Is "google-api-python-client" library under development ? Will there be support as and when Google-Cloud has more features adding to its services & that incorporating into "google-api-python-client" library ?

This comment has been minimized.

My current code infra depends on this library. Should i consider migrating to another library which would be there long term ? Which is the other library that i should think of moving to ?

We will continue to address issues in google-api-python-client until we formally deprecate it and then a year after that. We do not have any plans to do right now or any timeline. For cloud APIs, many of the Cloud Client Libraries are now GA and we suggest using those for new projects.

I've been using google-api-python-client library & it's not thread-safe. So the library that you'll mention in answer to above question will be thread-safe ?

This comment has been minimized.

I have begun using this library on a "serverless" project where I'm making use of Google services and APIs in programs that exist within ephemeral containers. Storage would be helpful as I'm concerned there may be thousands of access tokens for a refresh token at any given time, eventually hitting a limit.

I'm not super familiar with oauth flows and architecture, but here are a few things that come to my mind:

If all clients try to refresh the token at the same time we run into a thundering herd situation

Ideally would only work with the central store when the token is near expiration or invalid

High-level storage approach should work with anything from a relational DB with row locking to an eventually-consistant key-value store

I think this is a happy compromise between collisions, load on the database, and load on the authentication server. The 5 to 10 minutes I pulled out of the air, with the lower bound being your choice of 5 minutes clock skew (PS I agree with that choice as it's what MIT kerberos and Microsoft AD Kerberos by default... a lot of people are used to that number). I'm sure we could put a bit more rigor into finding the upper bound.

I do like the idea of a more generic interface for storage, however, if this is going to be part of the first-run experience working with Google APIs on one of the most popular beginner languages, perhaps there should be some batteries included for redis and certainly for cloud memory store. Let people like me contribute the AWS plugins.