Batch Size Greater than 10?

[seanohollaren]

Background

Has there been any thought given to allowing a batch size greater than 10 to be specified? I appreciate that the library currently maps 1:1 with the actual ReceiveMessage SDK operation, which has a limit of 10, but it seems to me that the code could be modified to perform n number of ReceiveMessage calls, concatenate together the responses, and continue on as normal with the same strategy employed at the end when it comes time to call deleteMessageBatch.

What do the maintainers think of this idea? This library is a fantastic way to interact with SQS and enabling larger batches to be received out of the box would be a huge boon to a lot of its consumers.

Objectives

1. Allow a batch size greater than 10 to be specified, resulting in the same fundamental behavior but with larger message batches (and a slightly longer delay before the promise is resolved as the larger batch is accumulated).

[nicholasgriffintn]

There is an item in the TBD section of our roadmap to look into it, and some work was previously done by the community here to build concurrency in, however, this really still needs to be looked at.

At the moment, I would consider if it's better to just open up the poll functionality and let users build concurrency in themselves, however, what you suggest also sounds like a viable thing to look at.

Ultimately, we're open to look at suggestions, but we'd preferably like to implement it in a way that's maintainable and doesn't require additional third parties.

[seanohollaren]

Apologies for missing the previous discussions! I missed them in my searches.

I think a very simple way of building this in could be just using Promise.all to send the appropriate number of ReceiveMessage and DeleteMessage requests. FIFO queues would require that the maximum batch size be set to a certain size to stay clear of service quota limits, but my understanding is that non-FIFO queues support a nearly unlimited number of calls.

Allowing users to specify their own Promise-based polling and deleting functions would certainly allow for a lot of flexibility too. That's another solution that would unblock this functionality so that each user could implement their own version.

[nicholasgriffintn]

Not at all, it was an PR before (we didn't have discussions enabled back then), I'll treat this as the discussion for the suggestion from this point.

Thanks for that feedback as well, I think it just requires a bit of thinking into the options and their outcomes.

Needs something similar to an RFC potentially, I may create one when I have time to sit down outside the day to day.

[schmod]

FWIW, we've been using the implementation from my PR in production for quite some time with no issues.

I'm not sure I'd agree that you could achieve the same thing by opening up the polling implementation. Apart from requiring a somewhat tedious amount of boilerplate to write, you still wouldn't be able to have local concurrency control, or the ability to schedule when the poller gets called (both of which are important for my use-case).

I will say that I have not tested my implementation against FIFO queues. (I think it should work, given the semantics of those queues, but I'd want to validate that assumption!)