Use CloudEvents as standard event schema

[liamwh]

CloudEvents aims to be the universal standard for event schemas.

There is an SDK for Rust.

It would be fantastic if we could ensure the events published by the framework are stored in the database as a CloudEvent type with the data in the data field.

Additionally, I would advise using the ULID crate for the ID if you're open to this suggestion.

[aurelien-clu]

I also find ULID to be more useful.

If need be I could do PRs (to every CQRS repo) adding a feature flag to enable ULID instead of UUID.

with UUID (no difference / no breaking change):

cqrs-es = "0.x"
postgres-es = "0.x"

with ULID:

cqrs-es = {version = "0.x", features = ["ulid"]}
postgres-es = {version = "0.x", features = ["ulid"]}

[liamwh]

@aurelien-clu I think that's a great idea and good first step towards getting best practice event format stored in the DB! PR encouraged :)

[aurelien-clu]

I am unclear on the contribution guidelines so I will wait for the cqrs team to approve before I start 😉

[davegarred]

Support for different serialization formats has been a topic since the beginning of this project, primarily to support protocol buffers for improved speed and lower storage requirements. I think the primary format should remain JSON since that is by far the most popular format but adding support for additional strategies should be trivial once that change is in place. I'm not familiar with CloudEvents so I'll need to take a closer look as to what that might entail.

I've renamed this issue so we can track it here.

Regarding the UUID library. This is not used internally by cqrs-es but solely for demo and test purposes. Feel free to use whatever you prefer in your application, but it probably makes more sense to stay with UUIDs since that is more familiar to most (and judging by the library usage, an order of magnitude more popular).

[liamwh]

Hi Dave,

Regarding UUIDs / ULIDs, no worries and understood.

We're not talking about different serialisation formats here. CloudEvent is a CNCF standard event format specification.

The issue is that the columns you've selected for the events table, do not match the CloudEvents spec. Given we're storing events here, I feel that the CloudEvents SDK should be used both internally inside the framework, and also that the table schema should reflect the standard event spec.

The spec and the fields it entails can be found here.