Coinbase - provide an option to use the private methods instead of public methods to reduce rate limit errors about ccxt

[carlosmiei]

Hello @jtashiro, we will take that into consideration but those endpoints are only called "once per instance", to cache and load the markets so it shouldn't have that much impact.

[jtashiro]

Hello @jtashiro, we will take that into consideration but those endpoints are only called "once per instance", to cache and load the markets so it shouldn't have that much impact.

I'm comparing 4.2.51 to 4.3.28 to identify the change that is causing me to encounter 429 Too Many Requests, when running the same python scripts. 4.2.51 works fine, no issue with 429, but 4.3.28 fails in the same spot each time on the public method I highlighted above.

4.2.51 fetch_tickers_v3() -> v3PrivateGetBrokerageProducts()
4.3.28 fetch_tickers_v3() -> v3PublicGetBrokerageMarketProducts()

Question is why was this changed to the public methods in 4.3?

I dont see a way to avoid hitting the rate limit when using the public methods and would need to refactor a lot of code to either introduce some back off throttling for no good reason.

I'll look further but the most straight forward for me was to replace the public with private methods as noted earlier.

[carlosmiei]

@jtashiro

Question is why was this changed to the public methods in 4.3?

We did this because for accessing public data like markets/candles/tickers/trades it should not be needed to have an account with the exchange, most exchanges provide this information publicly and we wanted to keep the same approach here.

[jtashiro]

Given the lower rate limit that is enforced on public apis, can these wrapper methods use the private methods when apiKeys present? That would make it transparent and not require an optional setting.

[carlosmiei]

@jtashiro I think it would be more "transparent" using the option. Which unified methods do you intend to use the private endpoints? fetchTicker/OHLCV/Trades ?

[jtashiro]

Yes those and any others - basically when API keys are present, use the private methods. But sounds like you are a fan of the option technique to drive that behavior instead of hiding that logic ?

[ttodua]

@carlosmiei is right, hiding it is not a good approach, we definitely have to offer an option so user could control it.
i'll be adding this shortly.

[ttodua]

I've linked PR. after it's merged and new package published, you can use ex.options['usePrivateEndpointsIfApikeysPresent'] = true (the keyname might be changed before merging, keep an eye on it), so thereafter all requests will use private endpoints (if api keys are present)

[carlosmiei]

@jtashiro Ok we just released a new version (4.3.32) with the changes, you can set exchange.options['usePrivate'] = True or provide usePrivate: True in params upon calling fetchTrades/OHLCV/ticker/Orderbook.

Let us know if anything!

[jtashiro]

This looks good. I’ll open a new ticket regarding the exchange name you’ve added for Coinbase Advanced. Is it possible to revert and preserve the name ‘Coinbase’ and add a new property describing the API or some other technique { API: 'Coinbase Advanced’, API_KEY: “CDP” }. The rationale here is that the exchange is still ‘Coinbase’ and the method for accessing the exchange is “Coinbase Advanced”.

…

On May 27, 2024, at 9:53 AM, Carlos Gonçalves ***@***.***> wrote: @jtashiro <https://github.com/jtashiro> Ok we just released a new version (4.3.32) with the changes, you can set exchange.options['usePrivate'] = True or provide usePrivate: True in params upon calling fetchTrades/OHLCV/ticker/Orderbook. Let us know if anything! — Reply to this email directly, view it on GitHub <#22571 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTDKBNG7Q2ZQCTRB4QOLELZEM3FBAVCNFSM6AAAAABICBXQHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZTGUZTGNBRGE>. You are receiving this because you were mentioned.