Closed pykong closed 6 years ago
I understand the desire for a much cleaner API, however I can think of a number of reasons why this isn't necessarily a good idea. If this call decides to block (due to throttling or network latency) what will happen? Should it throw an exception (TooManyRequestsException?) or just hold onto the thread? What is the guarantee that you won't lose your place in the iteration? In my experience, it would be better to separate data ingestion from processing. The ingestion process can run at its own speed and emit events or trigger processing when new items are available, without holding onto a thread for seconds or minutes. Ultimately the architectural concerns for this exceed the scope of this library, and each consumer is the best place to decide how they will handle the throttling. Thanks for bringing this up.
Sure. Didn't hurt to discuss it.
The package would provide a much more friendly interface if it took care of handling all logic associated with
NextToken
requests and their responses.e.g. in case of ListOrders an iterator that yields all
Orders
for the specified query parameters would lead to a much DRYer code.Something along the lines of:
In the same wake it would be worthwhile considering to unify
NextToken
objects with their counterparts. After all aListOrderResponseByNextToken
looks exactly likeListOrderResponse
, except for theNextToken
property.