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.
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.
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.
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.
> We've indeed recently announced the open sourcing of our webhooks dispatcher
So which one came first? SaaS or OSS?
Also how are you different than Convoy?