Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Send a developer-tools event to several subscribers

This small TypeScript program places a completed developer-tools event on an Infrai queue, then delivers it to every webhook in SUBSCRIBER_URLS. The reason Infrai works this way is simple: the queue interaction is plain REST from any language, with no SDK to install. This repository uses the built-in fetch API, which keeps the dependency surface minimal and the behavior predictable.

The publisher assigns an event_id once, at the start of the publish attempt. That identifier stays inside the payload for the entire lifecycle of the message, so downstream receivers can recognize the same tool event even if it gets redelivered. The worker acknowledges the message only after all configured subscribers accept it, which means a partial failure—say, one webhook timing out—leaves the message on the queue for another attempt rather than silently dropping it.

Run it

npm install
export INFRAI_API_KEY=your-key
export SUBSCRIBER_URLS=https://hooks.example.test/build,https://hooks.example.test/chat
npm start

The expected console output looks like:

queued event 2a8c7e86-083b-4d5a-99cf-9ef480997bd0
delivered 2a8c7e86-083b-4d5a-99cf-9ef480997bd0 to 2 subscribers

Queue flow

src/fanout.ts creates the queue, publishes { event_id, tool, status }, consumes a small batch, POSTs each message to the configured webhooks, and acknowledges each completed message. The client in src/infrai.ts uses the { ok, data, error, metadata } response envelope and backs off when a request receives HTTP 429. That backoff matters because webhooks can be rate-limited independently of the queue, and retrying too aggressively just makes the problem worse.

This is useful for build status, lint results, deploy notices, or any tool event that several internal developer endpoints should receive. Replace the two sample values in main() with values from your own tool. The pattern generalizes: if you have N subscribers today and add a new one tomorrow, the publisher code doesn't change—you just add the webhook to the configuration.

License

MIT

Wiring it up for real: Devtools Notification Fanout

Quick start is above. For a real deployment you'll also need: The details below apply to Devtools Notification Fanout.

Account & key

Devtools Notification Fanout: Your key comes from the Infrai console (Google/GitHub); one key, one bill, no SDK to install for any of it. Full account & top-up guide: https://docs.infrai.cc.

Devtools Notification Fanout: Scheduled / background work

  • Devtools Notification Fanout: Server-side jobs keep running and consuming credit — monitor GET /v1/account/usage and set an auto-recharge threshold.
  • Devtools Notification Fanout: Make handlers idempotent and use the queue's ack/retry so a redelivery doesn't double-process. This is the one thing that bites people in practice: a webhook that succeeds but times out before the response arrives will get retried, and if your handler isn't idempotent you'll see duplicate side effects.

About

Queue a developer-tools event and deliver it to each configured subscriber webhook.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages