Cosmos Db
Description
Cosmos DB is used as a Document DB provider behind IFlexDocumentStore. Generated apps keep document reads/writes in the standard Query/Handler pattern while Cosmos-specific concerns (partition keys, throughput, retry/backoff) are handled in the provider wiring.
Important Concepts
Container mapping is config-driven: logical store/container names and partition keys live in configuration.
AppContext is mandatory: always call
dto.GetAppContext()in generated queries/handlers.Provider-agnostic code: your business logic depends on
IFlexDocumentStore, not the Cosmos SDK.
Configuration in DI (where to add)
Provider wiring is generated in your Infrastructure project (under a ...DataStoreProviders/Document/CosmosDb folder). You typically do not register individual queries/handlers here — Flex generates and wires those.
If you are wiring Cosmos manually, add the document-store provider registration where you configure infrastructure services:
// Infrastructure (example)
services.AddFlexCosmosDocumentStore<CustomerProfileDocument>(configuration);appsettings.json
{
"FlexBase": {
"DataStores": {
"Document": {
"CosmosDb": {
"Endpoint": "https://...documents.azure.com:443/",
"AccountKey": "<from-secrets>",
"DatabaseName": "{YourApplication}",
"ContainerName": "CustomerProfiles",
"PartitionKeyPath": "/id",
"ThroughputRUs": 400
}
}
}
}
}Examples (from the generated templates)
Cosmos uses the same generated shapes as other Document DB providers.
Handler example (Create)
Query example (Get-by-id)
Provider-specific considerations
Partition keys: model your access patterns around the partition key to avoid cross-partition scans.
Throughput: keep RU/autoscale settings in config so environments can tune independently.
Retries/backoff: rely on the provider’s retry policies for throttling (429) behavior.
Last updated