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, , to make adapting those pre-existing messages into webhooks as painless as possible. Bridge 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 , by bundling up queue consumers, transformations, and Svix API client calls into a single process. existing event-driven architecture 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 API expects a JSON body to be prepared in this certain way, so a JavaScript function (similar to Svix's ) can be defined to reformat the message. Create Message Payload Transformations 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 the data can be done inline. Today, Bridge supports a short list of queue backends: GCP Pub/Sub RabbitMQ Redis SQS Our new library, , 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. Omniqueue 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 from Docker Hub, or build Bridge yourself from the source. Docker Image Check out the for details on how to build, configure, and otherwise get up and running. repo Sending webhooks is one place where using a message queue makes good sense, but so is consuming webhooks. Stay tuned for future posts 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 , or for the latest updates for the , or join the discussion on . Twitter , GitHub RSS Svix webhook service our community Slack Also published here

Read My Stories

Too Long; Didn't Read

Making security fun one episode at a time

How to Send Webhooks From Your Message Queue With Svix Bridge: A Beginner's Guide

Too Long; Didn't Read

Tom Hacohen

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

How to Send Webhooks From Your Message Queue With Svix Bridge: A Beginner's Guide

Too Long; Didn't Read

Tom Hacohen

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES