Support multiple events for HTTP binding

[lennygran]

There are use cases where multiple events should be sent via single web-hook request (aka batching.) Currently it assumes a single event for both, structured and binary modes. Does the HTTP binding in structured mode plan to support it?

[rperelma]

See also #330

[duglin]

@lennygran given #330 what are your thoughts on this?

[dmigliori]

I feel like the "conclusion" of many issues that generate a good discussion, but result in no changes to the spec, should still be included in the introductory documentation. This will enable implementers to have their questions answered as they read the documentation, rather than search closed issues for their answers.

[duglin]

@dmigliori yup - feel free to open up PRs to enhance the Primer doc. Any insight into our design choices will only help people understand things.

[duglin]

@lennygran given #330 what are your thoughts on this?

[cneijenhuis]

To clarify what I said in #330 :
I do not think that a single CloudEvent should contain multiple events. However, a transport layer may offer the possibility to transmit or receive multiple events in a single API call. Once we have the mapping between a (single) CloudEvent to a (single) transport layer event, it is trivial to use the API for transmitting multiple transport layer events with CloudEvents.

The HTTP binding is a transport layer, and therefore my comments in #330 imply that this would be the right layer to implement batching.

---

That said, most other transport layers supporting batching have a middle layer that allows to decouple batching between the producer and the consumer. E.g. the producer may batch 3 messages together, but the consumer batches with 10 messages, or none.

This assumption doesn't necessarily hold for HTTP. The problem I am seeing, in the context of a FaaS that allows to consume HTTP webhooks but doesn't have native support of CloudEvents, is that the producer then effectively reduces the parallelism. E.g. ideally, if there are 10 events, I'd like to have 10 function instances working on them in parallel. However, if the producer batches 10 events into a single HTTP webhook, only one function will be invoked that has to process all 10 events sequentially.

Therefore, I think batching should only be used (by the producer) to the extent the consumer wants to support it. Ideally the consumer is a middleware, and can re-arrange the batch sizes as necessary. But if it isn't, the consumer should be able to receive events one-by-one.

That would either have to go into the initial registration of the webhook, or we could introduce a third mode (e.g. structured-batched).

[deissnerk]

@cneijenhuis @duglin Just to be sure I understand where this discussion is heading. To enable batching on transport level, it would still be required to have this defined in the transport bindings, wouldn't it? If I choose cloudevents+json for http, my peer needs to understand that I may send an array of events and not just a single event.

[cneijenhuis]

@deissnerk I think it depends on the transport.

For HTTP, yes, we need to define it in the bindings if we want to support it. But HTTP is probably the exception, because we have to define much more for HTTP than we define for other transport layers.

For Kafka, as a counter-example, there is nothing to do. Kafka automatically batches messages under the hood, and that can only be influenced with some configuration (see http://kafka.apache.org/documentation.html#producerconfigs and bath.size and linger.ms). Once we have defined how a (single) CloudEvent maps to a (single) Kafka message, batching automatically works.
Similar when consuming messages, the API is batched by default.

Does that make sense? :) If yes, I can try to write a summary for the primary.

[deissnerk]

@cneijenhuis That perfectly makes sense. I generally agree with your statements from #330. I was just confused, because here only the primer was mentioned. At least for HTTP, an enhancement of the binding spec will be needed.

[duglin]

@lennygran in your opinion, does #370 (if merged) address your concerns?

[duglin]

@lennygran can we close this one given we define how to do batching now?