Exponential backoff
Closed this issue · 6 comments
Since the API is rate-limited, it would be good to have some sort of exponential back-off mechanism inside the wrapper, so that instead of throwing an exception, the wrapper would wait until the API is accepting calls again.
Implementing this inside the wrapper would be a lot easier, since the API has 1 method where all API calls pass through. The client using the wrapper can have many more.
What are your thoughts about this?
@nedelenbos I must say I was thinking about enforcing limits in the client itself, as we'd know the limits after the first call. However, I think back-off delays should be defined by the user. I was however thinking about making it easier for partners to enable this in their applications. Our servers would benefit greatly of this.
What do you think? Do you think it should be in the client? And if so, should you opt-in or opt-out?
According to me it should definitely be in the client! If I take a look at the application we're currently developing, we're doing calls to various methods of the wrapper. Adding products, categories, attributes etc. If I would write an exponential-backoff in our own application, I would have to make sure that every call to the SEOshop wrapper uses this exponential-backoff system. This would mean calls to the same mechanism, on different places in the code.
When the exponential back-off is defined in the wrapper, the only thing a partner needs to do is to enable/configure it, and no further could would be necessary.
Depending of the usecase I would opt-in and out. For our current application I know that doing 500(0) requests from 1 single script would not be unusual. By knowing this I would probably enable exponential back-off (this is an automated process, so I know that there isn't a user waiting on a response).
However if I would know that a user is waiting for a response, I would probably disable exponential back-off and catch the exception's myself.
We could edit the client so that it would enable the client to be wrapped in a adapter which enables exponential back-off, would that be something that works?
That would be fine by me! By doing that you'll ensure backwards compatibility, which is nice 👍
Agreed, we'll see how and when we'll do this 👍
btw... the API needs a lot more bulk and cascading possibilities. I am currently trying to sync product filters with an internal database. If you are using a lot of filters, a single product update can take 50 calls and more easily... to request the available filters and values, compare with internal settings, delete and create new filters.... phuuu... It is really hard to deal with this and the limits. I have an internal product DB here with more than 3000 products... all with filters, attributes, tags, images.... takes ages to get this updated by API.