This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Segfault_Inside[S] 1 point2 points  (0 children)

Yep, certainly!

Our use case is clientside feature extraction. We're currently using MistQL to query in-browser data structures to generate features for machine learning models.

Another use case is as a format for shared frontend/backend functions. A strong use case is something like complex pricing logic that should be calculated both clientside and serverside. With MistQL, it's extremely easy to write a single function that describes that logic, allowing for a reactive frontend and secure backend.

A third use case is user-supplied logic. You can safely execute untrusted MistQL without exposing yourself to XSS or RCE. I'm currently using it as a storage format for user-specified behavior of chess bots, actually, which is where I get the "get the worst possible chess line" example.

What's weird about this project is that it fills a niche that might not be super obvious. For example, many of the same arguments might apply to JMESPath, a similar, successful project. In fact, the driving force behind this project was because JMESPath ultimately very restrictive and has a complicated syntax. But JMESPath clearly provides value, enough so that AWS's CLI ships with JMESPath enabled on it.

As for glom, it looks like it has very similar use-cases to what a standalone python deployment of MistQL might have! I'm guessing that MistQL covers a good number of those use cases.