Send Webhooks from your Message Queue with Svix Bridge

For many of our customers, the webhooks they want to send start out as events flowing through internal message queues. We built our new agent, Bridge, to make adapting those pre-existing messages into webhooks as painless as possible.

Turning Your Events into Webhooks

Turning pre-existing messages into webhooks often means having to build something to pull messages off a queue, reshape them if needed, and finally send out a request to kick-off delivery to your webhook subscribers.

Bridge simplifies integrating Svix Webhooks with your existing event-driven architecture, by bundling up queue consumers, transformations, and Svix API client calls into a single process.

With a small amount of configuration, you can start consuming events, reshaping, and sending webhooks in minutes. You tell it a queue to read from, how to optionally reshape the payload, and let Bridge take care of the rest.

Here's an example configuration, reading from RabbitMQ:

senders:
  - name: 'send-from-rabbitmq-example'
    input:
      type: 'rabbitmq'
      uri: ${RABBITMQ_URI}
      queue_name: ${QUEUE_NAME}

    transformation: |
      function handler(input) {
        return {
          appId: input.key,
          message: {
            eventType: input.event_type,
            payload: input.data
          }
        };
      }

    output:
      type: 'svix'
      token: ${SVIX_TOKEN}

In this example, we're subscribing to messages from a queue, making the payload conform to the expected shape, including the required fields:

• appId
• message.eventType
• message.payload

Svix's Create Message API expects a JSON body to be prepared in this certain way, so a JavaScript function (similar to Svix's Payload Transformations) can be defined to reformat the message. By using a JS transformation in Bridge, we remove the need to pre-process the data in yet another queue consumer running elsewhere. Instead, reshaping of the data can be done inline.

Today, Bridge supports a short list of queue backends:

• GCP Pub/Sub
• RabbitMQ
• Redis
• SQS

Our new library, Omniqueue, was developed in tandem. Once adopted in Bridge, we'll be able to add support for more backends by expanding capabilities on the omniqueue side. Omniqueue should make it easier than ever to provide access to more queue backends.

For more on Omniqueue, check out Omniqueue: A Queue Abstraction Layer for Rust

Wrapping up

Bridge can be a low-code option to conveniently start sending webhooks from the messages already flowing through your organization.

If you've got events flowing through a message queue and want to publish them as webhooks, give Bridge a try!

• Grab the Docker Image from Docker Hub, or build Bridge yourself from source.
• Check out the repo for details on how to build, configure, and otherwise get up and running.

Sending webhooks is one place where using a message queue makes good sense, but so is consuming webhooks. Stay tuned for future post on how Bridge can help streamline a set of best practices for receiving and handling webhooks.

For more content like this, make sure to follow us on Twitter, Github or RSS for the latest updates for the Svix webhook service, or join the discussion on our community Slack.