https://serverless-stack.com/ logo
#sst
Title
# sst
s

Seth Geoghegan

03/02/2021, 4:41 PM
which results in an error
Copy code
TypeError: Cannot destructure property 'sqsQueue' of 'props' as it is undefined.
    at new Queue (/Users/sethgeoghegan/dev/signup-and-run/node_modules/@serverless-stack/resources/src/Queue.ts:23:7)
f

Frank

03/02/2021, 4:45 PM
@Seth Geoghegan let me send you a snippet
s

Seth Geoghegan

03/02/2021, 4:45 PM
👍
f

Frank

03/02/2021, 4:47 PM
btw, does your DLQ have a consumer?
s

Seth Geoghegan

03/02/2021, 4:47 PM
no consumer yet, no. I don't have a plan for how to process failed events just yet, but i'd still like to make the DLQ available as a destination
I mean, I guess I could create a consumer that logs the error
f

Frank

03/02/2021, 4:50 PM
Copy code
import * as sqs from "@aws-cdk/aws-sqs";

// Create the DLQ in native CDK
const deadLetterQueue = new sqs.Queue(this, "DeadLetterQueue");

// Create the main queue in native CDK
const mainQueue = new sqs.Queue(this, "MainQueue", {
  deadLetterQueue: {
    maxReceiveCount: 1,
    queue: deadLetterQueue
  }
});

// Pass the main queue into sst.Queue and add a consumer
new sst.Queue(this, "WebhookQueue", {
  consumer: "src/webhook_processor.handler",
  sqsQueue: mainQueue,
});
s

Seth Geoghegan

03/02/2021, 4:50 PM
I'm not sure if what i'm doing is a good practice or not. I figured the first step was to create the DLQ so the failed messages don't get stuck in my main queue. The second step, which i haven't figured out just yet, is coming up with a smart way to do something about the failures.
f

Frank

03/02/2021, 4:51 PM
Yeah, this is okay.. currently
sst.Queue
currently doesn’t support setting
dead letter queue
(coming real soon)
So for now, you can create the queue manually in native CDK, and pass the queue in to
sst.Queue
So when you pass
sqsQueue
in,
sst.Queue
will use it instead of creating a new queue
Does that make sense?
s

Seth Geoghegan

03/02/2021, 4:56 PM
Yeah, that makes sense. Trying it out now. Thank you!
Looks like that did the trick
I'm replicating an SQS proxy API endpoint I built in my Serverless app using the serverless-apigateway-service-proxy plugin
The live lambda development environment will be a big win here
f

Frank

03/02/2021, 7:05 PM
Oh nice! How are you configuring the Api to the queue? I’d love to share it with other in our migration guide https://docs.serverless-stack.com/migrating-from-serverless-framework
s

Seth Geoghegan

03/02/2021, 7:18 PM
I should have said "I'm trying to replicate.." I am fairly new at working with CDK, and the HTTP API proxy integration support in CDK is ... pretty painful
to me at least 🙂
f

Frank

03/02/2021, 7:20 PM
Yeah.. if u run up against anything tricky feel free to share it here.. we can look at it together
s

Seth Geoghegan

03/02/2021, 7:20 PM
I've been looking at how the SST API Construct is creating a LambdaProxyIntegration for each route, which gives me some ideas
Definitely. If i get it working, i'd be happy to share
f

Frank

03/02/2021, 7:21 PM
yup yup… it will probably go into SST natively at some point
s

Seth Geoghegan

03/03/2021, 10:29 PM
Welp, it broke my brain, but I cobbled together something that works.
This stack creates an API Gateway (v2) proxy integration to SQS.
Was way harder than I thought it would be. I suppose it's because the CDK constructs for APIGv2 are still fairly new. This seems like a pretty common use case for these services. I would have thought CDK would make it easier to stand up (or at least the docs could have given more/any examples).
f

Frank

03/04/2021, 10:19 AM
Thanks for sharing! Yeah this is a pretty common use case. I’m going to refer to this when we add support for it. https://github.com/serverless-stack/serverless-stack/issues/92
k

Karo

03/11/2021, 7:04 PM
@Seth Geoghegan your example is exactly what i needed 🎉 thanks for sharing