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.
Excellent thanks. Sounds like more of a philosophical difference but it will be interesting to see how that plays out. There's certainly room in the market for multiple players! It's a hard problem.
I don't know if I'd call us SaaS first, though we definitely spend a lot of time, money and attention making sure our SaaS offering is as reliable as it gets if that's what you mean.
FWIW, I've been an OSS developer and maintainer for all my life (my previous business was also open source), and open sourcing Svix was always the plan. It was literally one of the first tickets I opened for the team, and our first public commit was in Feb 2021.
We've indeed recently announced the open sourcing of our webhooks dispatcher[0]. It's written in Rust, so also a single binary with no third party dependencies. We do NOT however offer in memory storage. This is on purpose, as persistence is a requirement for robustness.
> We do NOT however offer in memory storage. This is on purpose, as persistence is a requirement for robustness.
Oooo shots fired. :)
I can see arguments both ways. You're totally correct in that queue robustness requires persistence. That being said, if it's an open source tool then it can make sense to offer in memory storage since they may have persistence in a different part of the stack.
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.
Sure, but then you'd want to hide it behind an `--i-really-know-what-im-doing` flag to prevent people from shooting themselves in the foot.
Also, even if the persistence is elsewhere in the stack, it's not obvious to me how disaster recovery will actually work. Same with accounting (e.g. marking a message as sent). I'm not saying it's not possible, it's just not immediately obvious to me how you can make that both simple and robust.
