Though the data I do have: how many people adopt these advanced endpoints in practice (as we offer these), and it's less than webhooks.

These weaknesses are why we[1] added FIFO endpoints, Polling Endpoints, and what we call "Svix Stream" as ways to do ordered state synchronization (each with its own tradeoffs). This lets people consume the events in the way that best fits their use-case. We are working on more things to make the state sync even easier. I'd love to hear about more challenges people are facing with webhooks, as we want to make these things better.

OP: I'd love to hear more about your thoughts there, and will send you an email in a moment.

P.S, if you're unfamiliar, please check out Standard Webhooks[2]. It's a spec we created to help with signature verification that has been adopted by OpenAI, Anthropic, Google, and many others. We are chipping at one webhook challenge at a time. :)

1: I'm the founder of Svix (mentioned in the post), we do webhooks infrastructure as a service.

2: https://www.standardwebhooks.com/

Comments URL: https://news.ycombinator.com/item?id=49114559

Points: 4

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=49089254

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49036092

Points: 2

# Comments: 0

The US has the 5th amendment protecting you from self-incrimination, while in the UK you can go to prison for not divulging your encryption password (even if you forgot it!).

The US doesn't have ISP/DNS level blocking for all I'm aware of, but there's the ultimate blocking that sometimes does happen (FBI raiding your servers, even if outside of the US).

The US has the 1st amendment protecting speech, while in the UK people routinely get arrested for social media posts.

Maybe there are areas where the UK is better about privacy/freedom than the US, but no examples immediately come to mind.

Diom includes implementations for common backend primitives such as cache, key-value, idempotency, rate-limiting, queues, and streams, with more on the way.

While building Svix, we had to reimplement the same backend primitives that everyone have to reimplement. We also constantly felt the tension between building something custom on top of existing infra (like Redis and Postgres) and adding more dedicated services (like RabbitMQ and Kafka) which we would then need to configure, operate, back up, and maintain. This was even worse for us because Svix is open-source, so additional infrastructure meant additional burden on our customers.

Six months ago we finally decided to build Diom, and focus on developer experience and ease of operation. It's open source, self-contained, and manages its own storage using fjall (a fast LSM-tree-based storage similar to RocksDB). It requires no external runtime dependencies (no redis/postgres/kafka/etc), and supports running as a single node or a highly-available Raft based cluster.

The goal of Diam is to provide developers with the backend primitives they need without having to write custom code on top of Redis, RabbitMQ, Kafka, or even need to run them at all. It currently supports cache, key-value, idempotency, rate-limiting, queues, and streams. We also plan on adding auth-tokens, distributed settings, feature flags, and other common components; as well as adding more functionality to existing components.

Diom favors ease of operation over scale, so it doesn't match Kafka-level throughput or very high QPS like Redis and Dragonfly. However, most products and developers don't process multiple terabytes and billions of events per second anyway. That said, Diom can still hit high performance for its target use-cases as it implements higher-level primitives rather than basic operations. Additionally, because the primitives live in the same process as the storage, there are fewer network round-trips, which keeps latency low.

It uses HTTP/2 with msgpack as the wire protocol (works fine from browsers), and ships a CLI and SDKs for Python, TypeScript, Rust, Go, and Java, with more on the way.

We have Svix fully ported to Diom and continuously running tests and simulated workloads in one of our staging environments. GA (general availability) is planned for later this year, once we've moved Svix production workloads over.

Repo (MIT licensed): https://github.com/svix/diom

Docs: https://docs.diom.com

Live playground: https://diom.com/playground

I'm excited to finally share Diom, and would love to hear what everyone thinks, and what other components you would like us to build! Would also love help figuring out what to call this. We currently say "component platform," but I'm not a fan of the name.

Comments URL: https://news.ycombinator.com/item?id=48210123

Points: 2

# Comments: 0

Diom includes implementations for common backend primitives such as cache, key-value, idempotency, rate-limiting, queues, and streams, with more on the way.

While building Svix, we had to reimplement the same backend primitives that everyone have to reimplement. We also constantly felt the tension between building something custom on top of existing infra (like Redis and Postgres) and adding more dedicated services (like RabbitMQ and Kafka) which we would then need to configure, operate, back up, and maintain. This was even worse for us because Svix is open-source, so additional infrastructure meant additional burden on our customers.

Six months ago we finally decided to build Diom, and focus on developer experience and ease of operation. It's open source, self-contained, and manages its own storage using fjall (a fast LSM-tree-based storage similar to RocksDB). It requires no external runtime dependencies (no redis/postgres/kafka/etc), and supports running as a single node or a highly-available Raft based cluster.

The goal of Diam is to provide developers with the backend primitives they need without having to write custom code on top of Redis, RabbitMQ, Kafka, or even need to run them at all. It currently supports cache, key-value, idempotency, rate-limiting, queues, and streams. We also plan on adding auth-tokens, distributed settings, feature flags, and other common components; as well as adding more functionality to existing components.

Diom favors ease of operation over scale, so it doesn't match Kafka-level throughput or very high QPS like Redis and Dragonfly. However, most products and developers don't process multiple terabytes and billions of events per second anyway. That said, Diom can still hit high performance for its target use-cases as it implements higher-level primitives rather than basic operations. Additionally, because the primitives live in the same process as the storage, there are fewer network round-trips, which keeps latency low.

It uses HTTP/2 with msgpack as the wire protocol (works fine from browsers), and ships a CLI and SDKs for Python, TypeScript, Rust, Go, and Java, with more on the way.

We have Svix fully ported to Diom and continuously running tests and simulated workloads in one of our staging environments. GA (general availability) is planned for later this year, once we've moved Svix production workloads over.

Repo (MIT licensed): https://github.com/svix/diom

Docs: https://docs.diom.com

Live playground: https://diom.com/playground

I'm excited to finally share Diom, and would love to hear what everyone thinks, and what other components you would like us to build! Would also love help figuring out what to call this. We currently say "component platform," but I'm not a fan of the name.

Comments URL: https://news.ycombinator.com/item?id=48120719

Points: 4

# Comments: 0

Diom is a single Rust binary that replaces Redis, RabbitMQ, Kafka, and a lot of custom code for many common use-cases. It's open-source, self-contained, and has no external runtime dependencies.

While building Svix, we had to reimplement the same backend primitives that everyone reimplements when building a service: robust caching, rate-limiting, idempotency, and more. We also constantly felt the tension between building something custom on top of existing infra (like Redis and Postgres) and adding more dedicated services (like RabbitMQ and Kafka) which we would then need to configure, operate, back up, and maintain. This was even worse for us because Svix is open-source, so additional infrastructure meant additional burden on our customers.

Six months ago we finally decided to build Diom. It's a self-contained open-source service that people can run in their infrastructure with a focus on developer experience and ease of operation. It manages its own storage using fjall (a fast LSM-tree-based storage similar to RocksDB) and therefore requires no external runtime dependencies (no redis/postgres/kafka/etc), and supports running as a single node or a highly-available Raft based cluster.

The goal is for Diom to replace Redis, RabbitMQ, Kafka, and a lot of custom code for most use-cases, by offering pre-built implementations for common backend primitives. It currently supports cache, key-value, idempotency, rate-limiting, queues, and streams. We also plan on adding auth-tokens, distributed settings, feature flags, and other common components; as well as adding more functionality to existing components.

The closest existing project is probably NATS with JetStream, which is also a single self-contained binary with KV, streams, and queues. One of the main differences is that Diom ships higher-level primitives like idempotency, rate limiting, and cache as first-class APIs, rather than something you build on top of KV and streams.

Diom favors ease of operation over scale, so it doesn't match Kafka-level throughput or very high QPS like Redis and Dragonfly. However, most products and developers don't process multiple terabytes and billions of events per second anyway. That said, Diom can still hit high performance for its target use-cases as it implements higher-level primitives rather than basic operations. Additionally, because the primitives live in the same process as the storage, there are fewer network round-trips, which keeps latency low.

It uses HTTP/2 with msgpack as the wire protocol (works fine from browsers), and ships a CLI and SDKs for Python, TypeScript, Rust, Go, and Java, with more on the way.

We have Svix fully ported to Diom and continuously running tests and simulated workloads in one of our staging environments. GA (general availability) is planned for later this year, once we've moved Svix production workloads over.

Repo (MIT licensed): https://github.com/svix/diom

Docs: https://docs.diom.com

Live playground: https://diom.com/playground

I'm excited to finally share Diom, and would love to hear what everyone thinks, if you find it useful, and what other components we should build! Would also love help figuring out what to call this. We currently say "component platform," but I'm not a fan of the name.

Comments URL: https://news.ycombinator.com/item?id=47996356

Points: 5

# Comments: 0

As for the $40m number: I also saw this number, but I don't think it's correct. E.g. Germany recently bought 140 of them for $165m. Ref: https://www.i24news.tv/en/news/israel/defense/1649255166-ger...

For perspective: Patriot missiles cost $4m each.

As for traveling to the future: that sounds like fun!

So you support many more than you realize!