Knative eventing delivery format

[Walter Medvedeo]

Hello team,

I have two simple services using knative eventing like these:

MyService1 -> (write event in "structured" format) -> K_SINK -> Broker -> Trigger -> MyService2

I have noted that MyService2 always receive the events in "binary" format, no matter in which format MyService1 are producing them.

In my example I'm using all the default configurations, i.e., no special settings on the channels, etc.

My question is, do we have any configuration alternative to be able to make MyService2 receive the events in "structured" mode?

Many thanks in advance!

Regards,

Walter.

[Pierangelo Di Pilato]

Hi Walter,

this is currently not configurable, we use binary because it's much
more efficient for routing, would you mind sharing why and how
receiving structured events helps you?

Thanks,
Pierangelo

> --
> You received this message because you are subscribed to the Google Groups "Knative Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to knative-user...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/knative-users/5a0dc05c-fd75-44d5-94b7-3a4f698895cen%40googlegroups.com.

[Walter Medvedeo]

(I forgot to copy the response to the group, sorry for the duplicaion...)

Hi Pierangelo, many thanks for the quick response.

I undestand the benefits of managing the binary format internally, and I agree.

This also helps the filtering by triggers, etc., So all good.

In fact I have my own servicies, MyService3  programed in a way that they support both binary and structured formats.

For the case of MyService2, we have that this particular service is based on the quarkus reactive messaging API.

Originally this service was working with the katka conector, and knows how to deserialize the structured mode.

Now, we are exploring an easy way, to move this service to knative eventing by only changing the connector to quarkus-http, and keep the reactive messaging API base code we already have. And this is the the motivator of the question.

I think the benefit could be to have lets say, quarkus reactive messaging based services that you can easy change (e.g. by using profiles) from a karka connector based versión to a knative based versión

Regards,

Walter 

[Pierangelo Di Pilato]

Hi Walter,

I'm not that familiar with Quarkus and the messaging API, however,
does that mean that quarkus-http doesn't support CloudEvent binary
mode for HTTP?

> To view this discussion on the web visit https://groups.google.com/d/msgid/knative-users/b452518c-6085-48d1-9182-848160ab4de1n%40googlegroups.com.



--

Pierangelo Di Pilato
Senior Software Engineer
Red Hat, Inc
https://www.redhat.com/