QueryState/QueryStateAsync generic fluent builder for JSON query generation
WhitWaldo opened this issue · comments
Today, the QueryState and QueryStateAsync methods have developers provide a store name and a JSON-based string representing the query they want to perform against the state. This provides excellent versatility to the end user to construct the query how they would like. However, I would propose that Dapr should also come bundled with a means of preparing such a query instead of just leaving it an open-ended question and pointing at the documentation.
I have just finished building a fluent API for building a conforming query string (supporting paging, sorting and filtering). It's passing the unit tests and while I was assembling the build pipeline to put it in a private NuGet package, it occurred to me that I could just as easily contribute it to this project as well so others could use it going forward as well.
The biggest question in my mind is where I should put it. As a fluent API, it spans several interfaces, enums, records and a JsonConverter class (implemented with System.Text.Json so as to avoid other dependencies), so while I think it makes most sense to put into a single file in Dapr.Client, say StateQueryBuilder.cs and then to put all the associated tests in tests\Dapr.Client.Tests\StateQueryBuilderTest.cs, does this align with the vision of how this project should be organized or should I put it elsewhere?
Second, this produces a JSON string output. I don't think an overload is necessary on QueryState or QueryStateAsync to point to this. Rather, I think it'd be useful to point to its existence in the .NET documentation in an opt-in capacity. To that end, to make documentation changes, will that require a separate proposal in dapr/docs or should I simply submit a PR there and reference back to this issue?
Thank you!
A fluent API for using the query state sounds great, as I've never fully grok'd how to build complex compliant query JSON myself. However, the query API in the Dapr runtime remains in the "alpha" state, with limited support from individual state stores, and there doesn't appear to be a significant push to move it forward. Given that, it might not make sense to add new query-related APIs to the existing SDK given the risk of the query API not ever becoming "stable".
That said, a separate NuGet package outside the Dapr SDK seems like a reasonable way to enable others to benefit from your hard work.
(Disclaimer: just my own opinion, not being a maintainer or approver for the SDK.)
@philliphoff I appreciate the thoughts - that's more than fair. If there's interest, I can always lift and shift into the .NET project somewhere. I'll write a follow-up note here once I've published the NuGet package.
I've open sourced this project as Innovian.Contrib.Dapr.StateQueryBuilder and published it to NuGet under the same name. I'd be happy to build it into the Dapr .NET SDK via a PR if there's any maintainer interest, especially if the query functionality graduates from its current alpha state down the road.