It works great for static credentials. As a product I think about adding couple more things that might be helpful here (Btw I am not the client for this, I just happen to know them as practical problems)

1. Support for OAuth Client credentials - Gateway does the OAuth dance to get the access token, this is quite practical and even useful in case of regular services running across clusters and sharing the same clientId-secretId

2. Support for request retries on certain failures and short circuiting in other cases

▲

Jonathanfishner 5 hours ago | parent [-]

thanks, both are useful.

1. we support OAuth apps today, and we're growing the catalog based on demand. we support rotating and refreshing tokens for those.

2. I'd like to understand your case better. sitting in the request path means we could own retry mechanisms, but I'm curious what made you think of it, what kind of use cases did you have in mind?

	▲	sandeepkd 4 hours ago \| parent [-]
		Almost every API caller has to add the logic for retries based on the response codes, centralizing it with the gateway optimizes the repetitive code across the clients. Trip breaker patterns are good for resource usage on both sides (client and server) when you know things are not working. In addition to that it also saves on cost for the clients if every call is billed irrespective of success or failure.