How are folks implementing EventBridge via SST? I see the Cron construct that references EventBridge for scheduled jobs and the Queue and Topic constructs that implement SQS/SNS, but nothing that seems intended to use EventBridge for an event bus. Is there a way to leverage the current SST constructs for this, or do you have to work around it using CDK directly in some way? Thanks

Hey @Clayton what’s ur use case? I can put in support for EventBridge this week.

I'm currently using EventBridge directly. I haven't had much need outside using CDK directly but just getting started

@Clayton, to elaborate on my ask above, which sources and targets do you need? I can add support for them first.

Thanks @Frank. I’m admittedly new to building something like this in serverless, so I may be overcomplicating things, but in general I’m trying to use EventBridge as the primary spine for pub/sub between the other parts in the system (DB, SQS, Lambdas, etc). From what I’ve been able to dig up, it sounded like EB is the current best practice for consuming and distributing events in an AWS architecture. More detail on my specific use case are in this thread - https://serverless-stack.slack.com/archives/C01JG3B20RY/p1627077466373700?thread_ts=1627068341.365500&cid=C01JG3B20RY Thanks again for the help.

Ah yup.

What would sst add on top of the SQS eventbridge target which cdk supports?

Thanks @Frank and @thdxr Is it also possible to connect AppSync to EB with SST (in place of SQS, if wanted)?

@thdxr I’m thinking similar to our

Topic

constructs where you can add

Function

and

Queue

subscribers to it. Something that looks like:

const myQueue = new sst.Queue(this, "MyQueue", {
  consumer: "src/consumer.main"
});

new sst.Rule(this, "MyRule", {
  eventBus: bus,
  eventPattern: { .. },
  targets: [
    "src/lambda.main", // sst.Function target
    myQueue,           // sst.Queue target
  ],
});

Ah cool. One thing to keep in mind is that it's generally best to avoid having more than one target per rule. After writing these manually (especially with having to attach permissions) what I found myself wishing for was a higher level construct that let me specify all my routing in a clean way eg

new sst.RuleSet(this, "RuleSet", {
  rules: [
    { pattern: { ... }, target(s): [...] },
    { pattern: { ... }, target(s): [...] },
    { pattern: { ... }, target(s): [...] }
  }
})

That's probably not the best idea but illustrates the concept

I see. Btw, can you show me an example of attaching permissions?

Here's an example of one rule

const func = new sst.Function(this, "notifications_booked_lambda", {
        handler: "src/domains/notifications/booked.handler",
      })
      func.addToRolePolicy(
        new iam.PolicyStatement({
          actions: ["ses:SendEmail"],
          resources: ["*"],
          effect: iam.Effect.ALLOW,
        })
      )
      new events.Rule(this, "notifications_booked", {
        eventBus: bus,
        eventPattern: {
          detailType: ["nori.calendar.booked"],
        },
        targets: [new targets.LambdaFunction(func)],
      })

Not sure if there's a less verbose way of writing this. Also often times the lambda target will also publish more events so I need to

bus.grantPutEventsTo(func)

Got it! Yup.. I will keep that in mind when designing this!

@Frank I think so. Let me know if you think I’m trying to go about this the wrong way, but I was looking to decouple the frontend requests from operations like DB updates to be able to handle errors, retries, etc. I was under the impression EB could/should be used as the main go-between for AWS resources, linking it up with Kinesis and/or SQS when needed.

Hey @Clayton, v0.37.0 now supports

EventBus

. Here are some examples - https://docs.serverless-stack.com/constructs/EventBus

Fantastic. Thank you @Frank