CloudEvents Event Specification | Hacker News Reader

CloudEvents Event Specification

cloudevents.io

77 pointsgtirloni14 comments

In Dapr (Distributed Application Runtime) we use CloudEvents as the language and provider / service agnostic event standard in our PubSub API building block. You can either provide a cloud event envelope yourself, or just provide the data and we will create the envelope.

https://docs.dapr.io/developing-applications/building-blocks...

AWS is noticeably absent in the list of implementations.

Changing the CW implementation which is so tightly coupled to many other AWS service might be overly tricky for AWS to accomplish over a short period of time. Hope it happens anyway

What about EventBridge?

AWS initially participated but was finalizing the Event Bridge format specification at a time when CloudEvents was not ready to go 1.0.

[edit: more simply MS & GCP said were insufficiently flexible for the Gorilla and AWS wasn't willing to delay shipping]

[I’m a PM on EventBridge] This is correct. Tim Bray, who built CloudWatch Events (which later became Amazon EventBridge) participated in the early CloudEvents spec, but as Erik said, CloudWatch Events launched before CloudEvents spec was finalized.

From the EventBridge perspective, we like CloudEvents and I expect that in future we will look to add support for it as an alternative to our existing envelope.

We extensively use CloudEvents at my current company. It does a good job standardizing the event structure. It does pose some challenges in statically typed languages when it comes to deserialization of event data. We use typescript, so no complains in that regard.

> It does pose some challenges in statically typed languages when it comes to deserialization of event data

Why is this a challenge? I've worked with similar things in the past and never ran into any issues-- isn't this a very well trodden path?

Base64 binary encoding? SMH… Also, why not just define RDF schemas and take it from there?

Any examples?

Debezium (a platform for change data capture) supports CloudEvents as one format [1] for emitting data change events to Kafka, etc. Judging by interactions with users, there seems to be some interest in this, but it's not huge.

[1] https://debezium.io/documentation/reference/stable/integrati...

We used CloudEvents internally at Segment as an evolution of the existing ad hoc format that evolved naturally over time. We were generally happy with its ability to bring some semblance of order, documentation, and guidance to our event format while also being flexible to changes. For example, we layered on the ability for internal services to return 207 Multi-Status responses to batched events and it didn't require major hacks.

> We used CloudEvents internally at Segment as an evolution of the existing ad hoc format that evolved naturally over time.

Is this just another way of saying "a really big JSON document"?

Many Azure services, SAP, PayPal, KNative, and far more.

Reply on news.ycombinator.com