starfish-ql VS svix-webhooks

SeaQL.org was founded back in 2020. We devoted ourselves into developing open source libraries that help Rust developers to build data intensive applications. In the past two years, we published and maintained four open source libraries: SeaQuery, SeaSchema, SeaORM and StarfishQL. Each library is designed to fill a niche in the Rust ecosystem, and they are made to play well with other Rust libraries.

SeaORM is the foundation of StarfishQL, an experimental graph database and query engine.

We are pleased to introduce StarfishQL to the Rust community today. StarfishQL is a graph database and query engine to enable graph analysis and visualization on the web. It is an experimental project, with its primary purpose (for now) to explore the dependency network of Rust crates published on crates.io.

That's exactly why we built Svix[1]. Building webhooks services, even with amazing tools like FastAPI, Celery and Redis is still a big pain. So we just built a product to solve it.

Hatchet looks cool nonetheless. Queues are a pain for many other use-cases too.

1: https://www.svix.com

Obviously Deno have vested interest it (and so do I as the founder of Svix[1]), but my take is that webhooks are great, though there are alternatives that could be better or complementary depending on the situation.

At Svix we also support running JS instead of sending webhooks (using Deno!), and it is very useful, but there are many limitations with this approach, and in general oftentimes people just want the data passed to their systems and deal with it there. Not write a bit of JS to do something ad-hoc.

So in short, like always with software engineering: "it depends" and there are tradeoffs to each approach.

1: https://www.svix.com

Svix - Webhooks as a Service. Send up to 50,000 messages/month for free.

We opted for a more manual approach, we have a ctx!() macro[1] we use for wrapping errors we want to enrich thay we use like this[2]: ctx!(some_fallible_fund(foo))?

I wodner if anyone is doing anything better? The nice thing is that we have relevant fields in our error type, so we get a full backtrace out if it.

1: https://github.com/svix/svix-webhooks/blob/main/server/svix-...

2: https://github.com/svix/svix-webhooks/blob/main/server/svix-...

This is what we do at Svix: https://docs.svix.com/receiving/source-ips

I've seen other companies (e.g. Stripe) also offer it via JSON, but I personally think it's not that important to provide it in a machine readable format if you don't plan on changing it; which you shouldn't as it'll break integrations. You should only add new IPs that can only be allocated to new customers.

P.S, if you'd like to start sending webhooks, you should probably check out Svix: https://www.svix.com

If I understand you, you just want some queue system, like kafka.But if you want a whole app who handle all your webhooks usage you can see : https://github.com/svix/svix-webhooks/

Might want to look into Svix and HostedHooks

Repository on Github: https://github.com/svix/svix-webhooks