[HN Gopher] Show HN: Svix - Open-Source Webhooks Service Written...
___________________________________________________________________
Show HN: Svix - Open-Source Webhooks Service Written in Rust
We are super excited to be open sourcing the Svix webhooks
dispatcher! Svix makes it easy to send webhooks. You send your
payload to Svix, and Svix takes care of deliverability, retries,
security, and more. You can read more about why we built Svix in
the original Show HN[0], though the gist is: our customers wanted
webhooks to build integrations and workflows around our product,
but we weren't willing to commit the engineering time, resources
and ongoing maintenance required of a webhook delivery system. Why
open source? On a personal level, I've been an open source
maintainer and contributor for many years, and I care a lot about
open source. So open-sourcing the Svix dispatcher was one of the
first tickets I created on our issue tracker. As for the company,
webhooks are currently a mess, everyone does them differently, with
differing levels of quality and features supported. This is
something we really want to fix. The Svix service is already making
a difference there (we're lucky enough to call some really cool
companies our customers), and open-sourcing the dispatcher is the
next logical step to increase our impact. Why Rust? It's really
fast, it makes writing secure and correct code easier, it's easier
to deploy and distribute (one static binary), and it's a lot more
fun. :) Webhooks are really cool, and I absolutely love what they
enable. They make the web compose-able, interconnected, and enable
people to automate a lot of their work! Our goal is to make them
easy, reliable, and consistent, so that more services offer them
and they are easier to consume. I'd love to hear your feedback!
We've incorporated most of the comments we got the last time[0]
(thanks again everyone!), and we would love to know how we can
improve the product further. Got any suggestions? Homepage:
https://www.svix.com Repo: https://github.com/svix/svix-webhooks/
Docs: https://docs.svix.com/ API reference: https://api.svix.com/
[0] https://news.ycombinator.com/item?id=26399672
Author : tasn
Score : 143 points
Date : 2022-02-15 15:38 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| onassar wrote:
| Very cool service. I built an experiment a few months back
| whereby I needed to trigger a webhook back to my server at a
| specific time in the future.
|
| Gonna share it here incase anyone else finds it useful:
| https://onassar.github.io/experiments/boomerang-webhooks
|
| It uses AWS API Gateway, Lambda and S3 to allow you to register a
| URL to be triggered at some future date.
|
| Hope it's helpful!
| wizwit999 wrote:
| You could also use State machines to implement this. For fun,
| I'm trying to think of a way to abuse SQS delays as well, but
| not sure if that'd work :)
| tasn wrote:
| SQS delays are limited to 15 minutes IIRC, and they are also
| a bit painful. You can definitely add a message with a
| timestamp and continue re-adding it to SQS until it's time,
| haha.
|
| Disclaimer: sounds horrible. :P
| onassar wrote:
| Haha yeh I try to stay away from SQS when I can ;)
| tasn wrote:
| Not exactly what we do, but you can definitely use Svix to
| build something like this!
| onassar wrote:
| Sorry if I wasn't clear. I didn't mean to imply that it's an
| alternative to Svix. More as something in the same space :)
| tasn wrote:
| Yeah, I didn't think you were, it was more of a general
| clarification!
| smashah wrote:
| Thanks for this OP.
|
| Looking forward to exploring how I can implement this in my own
| open-source project. Lots of users will find something like this
| useful.
| tasn wrote:
| Ping me at tom @ our domain (or see my profile), or come to our
| slack: https://www.svix.com/slack/
|
| We would be happy to help you set it up!
| kobyconrad wrote:
| Ohhh, congrats on going OSS! I've been watching you since I first
| saw your Show HN!
| tasn wrote:
| Thanks a lot! It's been a long time in the making!
| fallat wrote:
| https://github.com/muennich/sxiv
|
| Well this is going to be confusing.
| tasn wrote:
| Never heard of sxiv, but it is confusing, haha. I just typed
| "never heard of svix" when trying to type it. :P
|
| Anyhow, it's unavoidable, there is so much software around
| nowadays, similarities are bound to happen...
| techn00 wrote:
| Another open source solution written in Go is
| https://getconvoy.io/
| tasn wrote:
| One day I'll write a blog post about why we went with Rust
| rather than Go, but I'll resist the urge to hijack this thread
| for a Go rant. :P
| maith1 wrote:
| Ah we've been happy user of Svix, this is super cool! Congrats on
| the OSS, this could be useful for us going forward!
| tasn wrote:
| Thanks a lot! Yeah, I think it's extremely useful for local
| development, and self-hosting when you don't need the extra
| Svix resilience.
| CyberShadow wrote:
| What's with the "star and watch" animated GIF in the README?
| Should I start putting one in all my repositories? Should
| everyone be doing that as well?
| tasn wrote:
| Haha, we actually took the idea from other projects. :P
|
| It helps people that don't know that you can watch to subscribe
| for updates.
| CyberShadow wrote:
| May I suggest placing it in a <details> tag. I'm finding it
| difficult to pay attention to anything on the page when
| there's a constantly blinking animation on it.
|
| > It helps people that don't know that you can watch to
| subscribe for updates.
|
| How would one fairly decide which project READMEs should have
| such an animation, and which shouldn't? It certainly calls a
| lot of attention to itself.
| tasn wrote:
| No idea to be honest, we just thought it was a cool idea.
|
| > May I suggest placing it in a <details> tag. I'm finding
| it difficult to pay attention to anything on the page when
| there's a constantly blinking animation on it.
|
| I tried, but it starts hidden by default, so misses the
| point.
| pxeger1 wrote:
| Please don't turn GitHub into another YouTube - "don't forget
| to like and subscribe!!"
|
| :/
| allisdust wrote:
| One common pattern I noticed among all rust projects is that they
| support a lot of languages by providing a native client except
| for rust.
|
| I always wonder why this is the case. Is it due to lack of demand
| for it or because anyway the code is in rust so it is expected to
| be used as is (sometimes not possible at all to directly use the
| code like the recent edgedb showhn - though they have a
| conditions apply rust client)
| tasn wrote:
| It's lack of demand. Unfortunately there aren't that many
| people building a backend in Rust (they should, it's great!),
| so building a Rust library is not a top priority unfortunately.
| :(
| allisdust wrote:
| Ya. I guess we need some more maturity in Rust web
| frameworks. Specifically something like RoR and with some
| corporate backing. Current solutions are okay but they don't
| inspire much confidence due to slow pace of development and
| gaps wrt to frameworks in other languages.
|
| I'm using warp currently and recently did a load test on my
| backend. Performance was stunning so its definitely worth it.
| But these gaps do decrease the overall dev velocity as we
| have to make custom solutions where there aren't any.
|
| For example, I had to write some custom code which auto
| generates all model classes from db schema including
| functions for lazy loading various properties on the classes
| and regular CRUD. Took me a solid couple of weeks which I
| could have spent else where if I was using Java with JPA or
| RoR. Same with another piece to generate a warp compatible
| routes file from annotations on functions (including
| generating the corresponding struct for gathering post bodies
| and calling the actual handler function with the struct
| members).
|
| Worth it? Definitely. Wish its already available as some
| framework? Definitely!
| tasn wrote:
| We (as you can see) use Axum. It's new but great. It reuses
| a lot of the Rust ecosystem (Tokio, Hyper, Tower, Serde,
| etc), so it keeps on improving even without them changing
| anything. It also relies on a very strong infrastructure.
| iRomain wrote:
| This looks great! Never thought of even searching for such a
| solution. Bookmarked!
| tasn wrote:
| Haha, yeah. Before we created it (and looked around to see if
| anything existed) I wouldn't have thought of searching for
| something like this either!
|
| Edit: btw, it pains me that we don't, and we'll have one soon.
| :)
___________________________________________________________________
(page generated 2022-02-15 23:01 UTC)