sqs-consumer VS sqsiphon

You could utilize a wrapper like sqs-consumer. Check out their implementation.

To receive the messages from the queue, we will use the sqs-consumer library. The service will receive messages describing newly created orders. After some processing, it will change the order status in the table to ‘completed’.

As we built out this new system, we looked at the current module ecosystem to determine if anything would fit our needs to keep this queue cleared. Unfortunately, the best module we could find, sqs-consumer, did not support FIFO queues and the issues indicated they did not have any intention to do so. Therefore, we wrote sqsiphon. Our library heavily borrows from the public interface of sqs-consumer, but is implemented in a much different way. In particular, sqsiphon leverages the Node.js event loop through setImmediate to build the polling mechanism instead of relying on SQS's "long polling" feature. Additionally, sqsiphon utilizes the JavaScript prototype to reduce reliance on expensive closures. As a bonus, OpenTracing support is built-in to sqsiphon so that applications built with it can be monitored effectively. The result is a library that can poll SQS extremely quickly while requiring very little overhead.

sqsiphon, installable via npm install @knockaway/sqsiphon, is a library we wrote to help us improve our webhook event ingestion. Initially, we were relying on the scalable nature of AWS Lambda to handle our incoming webhooks. This worked for a fair amount of time, but as we grew, so did the number of incoming webhook events we needed to process. This resulted in Lambda overloading our data stores. To solve the problem, we built out a system that receives the webhook events and puts them into an AWS SQS FIFO queue.