BrighterCommand/Brighter

[Feature] For the Redis Gateway provide Cloud Events JSON as an alternative to Brighter's propietary message format

Open

#3615 aperta il 28 mag 2025

Vedi su GitHub
 (0 commenti) (0 reazioni) (0 assegnatari)HTML (295 fork)batch import
.NET0 - BacklogV10.Xfeature requesthelp wanted

Metriche repository

Star
 (1898 star)
Metriche merge PR
 (Merge medio 8g 18h) (29 PR mergiate in 30 g)

Descrizione

Is your feature request related to a problem? Please describe. Where we have built a messaging system over Redis, we used a proprietary format for the event that we serialize to the store. This prevents interop with other messaging frameworks, as both producer and consumer must understand our format.

Describe the solution you'd like

  • We need to continue supporting our proprietary Brighter format, as we have users of our Redis messaging.
  • Add support for CloudEvents JSON format. This should thus be an option described on Subscription and Publication (i.e., a RedisMessageFormat with Brighter and CloudEvents as options).
  • If we use CloudEvents, we use a different creator and publisher than if we use Brighter.

Describe alternatives you've considered For messaging, we can assume that the producer and consumer use Brighter (this assumption will not be true for Streams, but that is a separate concern). If you are using Redis as a queue in this circumstance, you likely need "decoupled invocation" over a full EDA, and so you are probably able to manage both sides. Even if we support cloud events in JSON format, your consumer may still not understand them. In that case, we could stick with our format. However, it would be better to be a good citizen here.

Guida contributor