Openiddict-core: Cosmos DB store

[NoahStahl]

Thanks for this work! I'm working on implementing into a project. Since I'm using Cosmos DB and am planning to implement custom stores against its .NET SDK, I was wondering if OpenIddict would be open to having that as a contribution alongside the EF and Mongo implementations? If so I could attempt one modelled after those and submit via PR, otherwise I'll just go down the custom path on my end.

[kevinchalet]

Hey @NoahStahl,

To be honest, I'm torn regarding Cosmos DB support:

• I like Cosmos DB's overall offer, specially the semi-structured approach (you can do the same things with recent versions of SQL Server and with PostgreSQL, tho).
• Entity Framework Core now supports Cosmos DB. Sadly, There are severe querying limitations and last time I tried, it didn't work well with the queries used by OpenIddict. I'll give it another try, to be sure.
• Cosmos DB can already be used flawlessly with the MongoDB stores (you have to tweak the initialization script a bit, as Cosmos DB doesn't support partial filters on unique indexes).
• The .NET SDK developed by Microsoft is only compatible with the SQL API, which means anyone using the Cassandra/Gremlin API wouldn't be able to use the OpenIddict <-> Cosmos DB integration. And since you can't even switch between APIs, it's a severe limitation.
• Objectively, the demand so far has been very low. I'm not really surprised, as Cosmos DB is an Azure-only solution, which makes it a fairly risky option (going to an on-premise model or switching to a different cloud vendor is not exactly a straightforward option).

My current feeling is that Cosmos DB is not attractive enough to justify developing and maintaining "official" stores for it.

[NoahStahl]

Thanks Kevin for sharing your thoughts. If you're not seeing demand for it, then it makes sense not to expand the maintenance surface. The EF integration for Cosmos does seem like more an afterthought, so I think the SDK is the best way to go if ever wanting to add a SQL-based integration. Regarding the API types, it is true there would be multiple scenarios to have full coverage, though Gremlin/SQL can combine.