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