subomi

If you specify one public key for all endpoints, It means all consumers can verify each other’s webhook data which is not what you want. You want each consumer to be able to verify only webhooks intended for them and fail otherwise.

We wrote a detailed guide on generating and rolling public key/secrets for your endpoints here [1]

[1] https://getconvoy.io/blog/generating-stripe-like-webhook-sig...

Convoy author here.

We also provide Signature verification. Static IPs are added security mechanisms for webhook consumers with strict network access rules.

Can anyone confirm this to be true, though? It seems everyone is recycling the same Bloomberg news :facepalm:

Nice! Thanks for the context, super helpful.

Yes, I am putting this on the roadmap! :)

Hmm. To clarify, do you mean Postgres as a queueing backend or storage backend?

We have it planned for a storage backend but not for queueing at the moment.

Yes, infact a distributed broker will be a better option. But some of these users like the visibility Convoy's UI provides and since they currently do this inter-service communication with a HTTP Post, they prefer to put Convoy in the middle to provide visibility and they can perform retries with Convoy.

It's the similar differentiation with Svix. They're both largely SaaS based as of today.

Convoy is largely OSS based. With a simple brew install you can publish events with Convoy from your local machine. :)

Hmm. That sounds more concise. Thanks for the feedback!

Oh, for clarity we do not support an in memory storage. We support an on disk storage & in memory queue. This enables the storage layer persist events across restarts.

Thanks!

If you can please paste the error here, so we can look into it.

Oh, YC funds open-source projects. They're several of them before us. :)

Honest feedback as well.

What we care deeply about today is simplifying and democrastising webhooks with Convoy. Under the MPL 2.0 License as I understand it, any modifications to Convoy must be made open-source as well which helps us reach our initial goal.

On building a viable business, we currently run a managed infrastructure, where users pay for our infrastructure and other collaborative features (team membership, rbac etc) to make it easier to work with the core.

Nevertheless, we are open to transitioning to a stricter license in the future that restricts other cloud platforms from competing with us with our software.

Yes, It's a big market and I am hoping for more brilliant use-cases outside what we're used to!

I just pushed a fix for this. You can try again! :)

Yikes. Checking this out.

Yes, we are very similar. But we are OSS first. Svix is SaaS first.

We're designing a tool to be flexible and simplify webhooks from a binary perspective. We already support multiple queuing & storage backends, we already support an in-memory queue and on-disk database, so you can run convoy as a single binary without third-party dependencies.

The thesis is if we can simplify webhooks like this, we can do more with a tool like this vs. just for API providers.

Although, I learned they recently open sourced some parts of their backend, but I think that's how we're fundamentally different.

Thanks for this well detailed feedback.

1) Yes, it's on our roadmap.

2) It was/is a design choice, we aren't so familiar with using redis as a persistence store. The goal was to enabled people switch backends depending on what they're comfortable with.

3) Thanks for bringing this up, there are a ton of things we should document.

4) We're working on improving things from a security perspective.

On application-wide keys, we're considering making this configurable, so you can choose what works best for you, we only started with app-wide keys, next is endpoint-keys. :)

On public/private keypair, this is new to me as well! we haven't found anyone doing this in prod. But yes, I can see how this can be useful in specific environments, definitely something we'd like to support.

Nice, nice. Please send us bug reports. :)

You're welcome. :)

Oh, yes.

So essentially Convoy's queue mechanism works as a delayed job queue (basically how retries in webhooks work e.g. Stripe will send the event to you every hour for the next 72 hours). When the endpoint is unaccessible it backs up and schedules the retries at a future time on the queue.

The implementation under the hood is a combination of redis zset + redis streams. :) When it maxs out retries the events are still stored in the DB and you can batch retry them once the endpoints become accessible.

Thank you!

Yes, we have plans to support PostgreSQL as a storage backend. At the moment, queue tuning parameters are not exposed as configuration parameters, they're based off a shared queue and we expose prometheus metrics over the shared queue. What use-cases do you have for tuning the queue?