claytondus / Claytondus.AmazonMWS

.NET Standard fork of Amazon MWS client
https://developer.amazonservices.com/
Apache License 2.0
33 stars 12 forks source link

Friendlier API for NextToken logic. #5

Closed pykong closed 6 years ago

pykong commented 6 years ago

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:

foreach(var order in mwsClient.YieldAllOrders(CreatedAfterDate, marketPlaceIds))
{
    // do something with order
}

In the same wake it would be worthwhile considering to unify NextToken objects with their counterparts. After all a ListOrderResponseByNextToken looks exactly like ListOrderResponse, except for the NextToken property.

claytondus commented 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.

pykong commented 6 years ago

Sure. Didn't hurt to discuss it.