[CosmosDBTrigger] Support single Document for binding

Right now we only support IReadOnlyList<Document> as an input type. That makes it tough to bind to anything at runtime b/c you could have many documents, which means that we don’t know which one to look at for your binding values (i.e. if you want to take a changed document and do an auto-lookup for related documents using a CosmosDB input binding).

Right now you have to either move to multiple functions joined by a queue or do the work yourself with DocumentClient internally. If we could support Document by itself as a trigger object somehow, that’d open up the possibility to have richer runtime binding here.

[mikhailshilkov]

It would also be nice to support single typed document, i.e. with a custom C# class instead of Document.

[paulbatum]

Yeah I’m not sure we should add this capability. Cosmos DB and Event Hubs have a lot in common when it comes to performance, and my findings for Event Hubs were that it is massively slower (and in the consumption plan, more expensive!) to write functions that receive a single EventData rather than an array. I’ve had a number of support cases that ended up being root caused to this issue. I’m considering a breaking change in V2 that would force event hubs to only support batched mode.

As @ealsur points out, a user can work around this by introducing a queue. This will work fine in low throughput scenarios. In high throughput scenarios, the developer really needs to do their processing in batches.