The code you’re talking about is a query. There are straightforward ways to do this now (including graphql). There are some issues with it, though. The query (

The code you’re talking about is a query. There are straightforward ways to do this now (including graphql). There are some issues with it, though. The query (or code, if you will) is separate from your data, meaning the aspects of the data a query depends on can’t change without breaking the query. You can have versioned apis and keep the old apis around, or have a query compatibility rewrite layer, etc. but obviously these kinds of things have serious complications/limitations. That approach is useful only in proportion to how broad, granular, and flexible the API is that you provide for the code/query to access. That sounds good, but such an API is a lot of work to create and a lot more work to maintain. An API is like a promise. If you make big promises, it will take a lot of effort to keep them. Also, realistically you have to limit arbitrary code sent in from untrusted sources that runs on your server. Even completely non-malicious users will write inefficient code or have inadvertent infinite loops that will eat up your compute budget if you don’t have controls in place. So... It’s very often better to add a “listeningStatsByGenre” endpoint if that seems to be what your users want.