subomi

I was here a few weeks ago, but I'm now on the CC train. The challenge is that the terminal is quite counterintuitive. But if you put on the Linux terminal lens from a few years ago, and you start using it. It starts to make sense. The form factor of the terminal isn't intuitive for programming, but it's the ultimate.

FYI, I still use cursor for small edits and reviews.

Why do we all of a sudden hold these agents to some unrealistic high bar? Engineers write bugs all the time and write incorrect validations. But we iterate. We read the stacktrace in Sentry and realise what the hell I was thinking when I wrote that, and we fix things. If you're going to benefit from these agents, you'd need to be a bit more patient and point them correctly to your codebase.

My rule of thumb is that if you can clearly describe exactly what you want to another engineer, then you can instruct the agent to do it too.

"They're not only awkward, but a 30 minute call takes up hours of my headspace." This is so apt. I've found that I have the best calls with people who provide specific notes about what they want to discuss—the more specific the note, the less headspace the call requires.

Maybe it could be done via email which is the point of this blog, but I never had the confidence to try that.

> I personally experienced said friction with ELv2, so makes me curious.

Can you share more? What friction did you experience with ELv2?

At this point, I think done chan should be an anti-pattern. Just use context for coordination and cancellation.

Congrats Mitchell, you've been a huge inspiration!

Reading this, I had an epiphany about why open-source software is essential. How do you peak under opaque abstractions? It's just not possible.

Imagine if Kubernetes was closed source & binary distribution only. Understanding abstractions is, I think, why being open source has become table stakes for infrastructure software.

> Adopting a non-compete license isn’t problematic in itself, it’s the trend of switching from an open source to a non-compete license after gaining significant success that is causing distrust in commercial open source software.

I shared a similar sentiment here [0]. The future of open source companies is taking a serious posture for it and clarifying as best as possible to all stakeholders involved what this stance is. Love this piece.

[0]: https://news.ycombinator.com/item?id=37215478

You can configure a custom response on every source configured on Convoy.

Paul, please write the article. I *want* to read it.

Hard agree. It's why I also believe that more & more companies will be more strategic with their licensing choice from the beginning. The common wisdom is to give it all away and grow at all costs, then switch licenses when there's brand value and the business needs revenue. This is poor because the license changes aren't bad in themselves because they still enable the individual developer to take enormous benefits, but they come with significant disadvantages like community drama, bad pr etc.

Sure thing. Well done!!

OP here.

Hey, I read your post and I'm a big fan of keygen. I plan on self-hosting it too for Convoy soon. :)

On the contrary, I like the name. :) And while you might have something that works for your company, it most likely won't meet many other companies needs. You can check webhooks.fyi[0] by Ngrok for the various implementations and edge cases.

[0] https://webhooks.fyi

What you described seems to me like webhooks. :) Webhooks aren't anything new really, Jeff Lindsay [0] coined them way back in 2007 while at Twilio but they aren't well understood and implemented today.

[0] https://twitter.com/progrium

Update: Nohooks Backend is now open source [0]. The goal is to collectively improve the polling system as well as generate more useful event types/payloads.

It was written in Rails :D

[0] https://github.com/frain-dev/nohooks-backend

I also do not see a good reason providers should mitigate this because we work well within the rate limit. Users already do this for services they care about if you do not natively support webhooks. DigitalOcean provides a URL to poll to know when your resources are fully provisioned.

Definitely, I'd love to see this happen. There are a whole lot of events we can generate from DigitalOcean Resources - K8s resources, firewalls, block storage etc.

Yup. Even DigitalOcean still doesn't have webhooks despite several user requests see here [0]

My business is building a Webhooks Gateway for delivering webhooks at scale - Convoy [1]. We use Convoy Cloud to power Nohooks. The goal is to show what's possible with Convoy so more providers can easily provide webhooks.

[0] https://github.com/digitalocean/api-v2/issues/14

[1] https://github.com/frain-dev/convoy

Hm. We hacked Nohooks pretty quickly off Convoy. Google auth & Notion docs were the fastest way to get auth and docs working, respectively.

We'll upload a data and privacy policy soon. :)

Most providers allow enough requests to make this work. E.g. Render supports 400 requests/minute for GET requests. It's enough to make this work. :)

Our goal is to increase the support of webhooks on the internet as much as possible. If they begin supporting webhooks, that'll be super cool. Hopefully, they use Convoy [0] :)

The intelligent aspect is working around rate limits.

[0] https://github.com/frain-dev/convoy

It's the usual how difficult can this be to build and operate. But what we've found is it's a pain at scale.

- How do you ensure that one or a set of bad endpoints do not clog the queueing system and delay delivery of other working endpoints?

- How do you provide easy tools for developers across projects to debug and fix webhook delivery problems?

- How do you ensure this container is multi-tenant to serve multiple teams and no two teams can view each other data?

- How do you ensure flexibility if a new team decides to use RabbitMQ instead of Kafka?

Once you start to factor in all this requirements & more, you eventually build your own Convoy. :)

TLDR: Convoy is that container that is flexible and powerful enough to manage all your webhooks needs.

Hey,

I responded to this in the comments below, see here [0]

[0]: https://news.ycombinator.com/item?id=35380957

Yup, it sucked! Users had to spin up a replica set all the time. Wasn't fun.

No, it can't. But it's a better replacement to receive the webhook before pushing it to zapier. Zapier doesn't give you good logs of webhooks to retry so you can re-trigger a workflow. Convoy does. :)

Thanks!

While we are pretty similar, several differences still exist today.

- Convoy is fully open-source, including our UI, adding multiple users, creating multiple projects, debugging & managing events. Svix has only its dispatcher open-source without a UI.

- Convoy directly integrates with PubSub systems like Amazon SQS & Google PubSub to ingest webhook events. Svix can only ingest events via a REST API.

- Convoy has features to send and receive webhooks. Svix has features to send webhooks only.

- Convoy is written in Golang, Svix is written in Rust. :)

It seems the organisation was flagged. See here [0]

[0] https://github.com/community/community/discussions/48173

Not at the moment. But this is currently on our roadmap. See here [1]

[1] https://github.com/orgs/frain-dev/projects/3

That's exactly what Convoy is. It's open source and supports both directions of webhooks. Receiving and Sending. See here [1] to get started receiving.

[1] https://getconvoy.io/docs/getting-started/receiving-webhook-...

Hey!

Convoy Founder here.

The way we think about it is API Gateways are the entry point to your API. Webhook Gateways are the exit point to the API. Hence the name. :)