Some do; Gitlab, Otka, and Pipedrive come to mind. I think this is more about the expectations set over the last decade. If you do things differently, there's a need to justify it, and it's just perceived as less secure, regardless of whether it's true or not (the pros and cons are well articulated in the article).
I expect to have to answer that question a lot! Hookdeck is an event gateway, an unopinionated event log/message bus that operates over HTTP. It can be used to send webhooks, but 80%+ of use cases are for inbound webhooks (consumer side).
We think outbound is best served with an opinionated, purpose-built product, as the use case is very specific. The common feedback we got from event producers is that they are all annoyed by the complexity and costs of their current solution for sending webhooks. We think OSS / self-hosted is the solution to that. We drew from our experience handling 100 billion events, but also kept the scope to the table stakes to be highly efficient and simple to operate.
Event destinations' support is also crucial here because it means more efficient delivery with fewer errors, which can drastically reduce the overhead of event delivery.
From most watch market positioning I'd assume this to be true. However for me it's the exact opposite, the watch is a tool to cut phone use. All I care about is LTE and the minimum I need to get around the world. SMS, calls, WhatsApp, Gmaps. All existing decent looking watch have atrocious battery life to offer all the health features.
Been looking for something like this! Doc search just hasn't kept up with what's possible now and is such a hassle to get the indexing to work properly. Will try it out!
YAML is just as effective at communicating data structure to the model while using ~50% less tokens. I now convert all my JSON to YAML before feeding it to GPT API's
I've heard this a lot but don't understand where this idea comes from. With JSON you can strip whitespace whereas with YAML you're stuck with all these pointless whitespace tokens you can't do anything about.
I would recommend the exact opposite, JSON is just as effective while using less tokens.
This example JSON:
{"glossary":{"title":"example glossary","GlossDiv":{"title":"S","GlossList":{"GlossEntry":{"ID":"SGML","SortAs":"SGML","GlossTerm":"Standard Generalized Markup Language","Acronym":"SGML","Abbrev":"ISO 8879:1986","GlossDef":{"para":"A meta-markup language, used to create markup languages such as DocBook.","GlossSeeAlso":["GML","XML"]},"GlossSee":"markup"}}}}}
Is 112 tokens, and the corresponding YAML (which I won't paste) is 206.
This is fair, typically I supply data as compact JSON but ask for responses as pretty printed JSON which is quite a large token penalty but tends to strongly reduce malformed JSON outputs.
Hookdeck is an infrastructure to consume webhooks simply & reliably. Incoming webhooks are challenging because they require a well-built (and often complex) asynchronous system. We help developers spend less building and troubleshooting issues with their webhooks to focus on their products instead. We offer a complete infrastructure to develop, test, receive, distribute and monitor webhooks and asynchronous events.
If you are looking to be part of a early stage team, fully leverage your knowledge & talent, have an impact on the product experience and implement features from scratch then this might be for you!
We are offering competitive compensation, generous stock options and liberty over your geo & schedule.
We are looking forward to hearing from you! Email me at alex@hookdeck.com
Hookdeck is an infrastructure to consume webhooks reliably. Incoming webhooks are challenging because they require a well-built (and often complex) asynchronous system. We help developers spend less building and troubleshooting issues with their webhooks to focus on their products instead. We offer a complete infrastructure to develop, test, receive, distribute and monitor webhooks and asynchronous events.
If you are looking to be part of an early (funded) team, fully leverage your knowledge & talent, have an impact, and work on hard scaling and concurrency challenges, this might be for you.
We are offering competitive compensation, generous stock options and liberty over your geo & schedule.
We are looking forward to hearing from you! Email me at alex@hookdeck.com
PH takes much more work and strategy but "success" is somewhat deterministic if you did your homework. In our case we saw similar uptake, signups and conversion then ~20h on HN front page over the course of a week. PH had a much higher half-life and we saw stable uptake for a few days while HN was all in the first few hours.
It was definitely worth it for us. Some of our best customers found us on PH and our lead investor first heard of us during our launch and reached out.
That's right. In the context of pushed events, you have very little margin for error. It's definitely "solvable," but a bit part of the problem is that for most tech teams, it's not their bread and butter. Handling webhooks reliably is just overhead and work they aren't putting into their actual product. So you end up with a lot of not-so-reliable implementations.
