MistQL uses a simple syntax to chain together complicated expressions in a fluent, easy to read manner. Readability is a major goal of MistQL.
Built for Browsers
MistQL has 0 dependencies and is hand-tuned for size. At 5.3kB gzipped, MistQL is specifically built to be embedded in size-restricted frontends.
Secure by Design
Queries in MistQL operate solely on the data you provide to it. You can run untrusted MistQL in your browser without risk of XSS.
More examples can be found by navigating to the "Try It Now" link.
Get count of a specific event
events | filter type == "submit" | count
Get count of all event types
events | groupby type | mapvalues count
Get the worst possible chess line
(lines | sortby overallScore)[-1]
Get emails of all users that use the Chat feature
events | filter type == "send_message" | groupby email | keys
Get usernames of all users who purchased before signing up
events | sort timestamp | groupby email | mapvalues (sequence type == "purchase" type == "signup") | filtervalues (count @ > 0) | keys
MistQL originated as a domain specific language for machine learning feature extraction on the frontend. Despite the widespread proliferation of learned features in neural networks, the need for handcrafted features still provides immense value in situations where classical machine learning models are more appropriate. MistQL was purpose-built to fill the niche of a domain specific language for feature extraction on the frontend.
Despite this initial motivation, MistQL is far more general than simply clientside feature extraction. MistQL can be used in a wide range of applications, including, but not limited to:
- User-submitted or untrusted logic
- Shared backend / frontend logic in scenarios where sharing code is infeasable
- As a serializable storage format for pure functions
How MistQL stacks up against other solutions
JMESPath and MistQL are similar in scope, but MistQL provides more out of the box, including arithmetic operations and regexes. A goal of MistQL is to not simply be a query language, but a language for defining ANY computation on a JSON-like object. One of the major driving factors behind MistQL is the fact that JMESPath isn't able to capture many of the key operations that MistQL provides.
JMESPath, however, has excellent cross-language support, whereas MistQL (for the time being) does not. If cross-language support is important, JMESPath might be your best bet, as MistQL doesn't yet have implementations in multiple languages.
JSONLogic is much smaller than MistQL, but also much less expressive. If the shared logic is extremely simple, JSONLogic might work better for you. If JSONLogic isn't expressive enough, or readability of JSONLogic becomes difficult, then MistQL will probably work better.
Emuto and MistQL have similar scopes, however Emuto lacks a number of features that mistql provides out of the box, including regexes and a large standard library.
jq is primarily used as a command-line tool rather than as an embeddable query language. Despite its ubiquity, jq doesn't have a robust, portable browser implementation, nor does it seem to be a major goal of the project. However, if your primary use case is as a CLI tool, jq is almost certainly your best bet, as it's a very well-known tool with a large amount of community support.
The decision criteria for whether to use jq or MistQL is very similar to the decision criteria for whether to use JMESPath or jq.