I live in a world where many of my users have learned SQL (of varying skill levels) and have readonly access to the company data warehouse. In my old desktop days, we had a number of “data mining” tools where a user could write SQL and plug it into a grid within the application. The grid supported sorting, filtering and row grouping, and this became a popular way for our users to dig around and find insights within our data. (There are modern BI tools like Tableau or PowerBI that are great at this type of thing, but my user base gives a collective “meh” every time I bring them up).
I’m wondering how an app like this fits in with the “contract first” world of ServiceStack. In this instance, there is no contract - the user is going to generate the data, and that data will end up in a grid that intelligently renders itself based on the dataset.
I have built a proof of concept service where the Response DTO declares a dynamic named Data, and I fill that with the results of the SQL (which serializes to JSON perfectly). Is that the best practice for implementing an app like this one?
(A slightly different use case might be that the developers will still write the SQL (to make sure it’s fast), and store the queries in the database and give them names. The users could pick the queries from a menu to populate their data mining grid. The benefit to this use case is that new services don’t have to be written for every new result set).