Reputation: 97
What is the recommended practice of using Cosmos client in a function app -
(1) Register a singleton in a function start-up class's service collection and constructor-inject it in functions' class. I am assuming I can use newest Cosmos SDK to create it;
(2) Use Cosmos binding features, which allow you get client from binding if you need more control over queries. This also allows you to use CosmosTrigger for feed processing;
(3) Mix (1) and (2).
The reason I am asking is Cosmos is now on newer SDK than the version used by Azure Functions bindings, and has some features I'd like to use like streaming iterators. I am tempted to use option (3), i.e. use both the injection and bindings where appropriate, but wouldn't it create two singleton Cosmos clients (one for 3.* sdk (DI) and one for 2.* for bindings)? Is it bad? If I use option (1) and go with my own injected client, would CosmosTrigger still require "old" sdk client?
Upvotes: 1
Views: 1165
Reputation: 3227
Bindings are purely a convenience and behind the scenes are doing exactly what you describe in #1. So if you want to use the newer version of the SDK or just like having more control over how things are instantiated go with #1. You won’t lose anything by it.
Triggers are slightly different only because it has to use the SDK included to trigger the function. So behind the scenes the Functions Host will spin up a CosmosClient
in this case and use it to pull messages. While it may work with newer versions specified, it is something to be aware that it may break too (would break locally and in cloud so you should be able to confirm pretty quickly). So in general if using as an input or output binding, totally fine to pull in whatever version of SDK you want. If you are using for trigger, it’s recommended to stick with the version pulled in by the extension (and ideally the extensions should be updated frequently to provide the latest versions of SDK as well).
Upvotes: 1