Thanks for your comment > using GraphQL in this manner does not appear particularly readable nor maintainable I fully agree. That's why I went to the trouble

Thanks for your comment > using GraphQL in this manner does not appear particularly readable nor maintainable I fully agree. That's why I went to the trouble to design a different syntax. As I mention in its repo (https://github.com/getpop/field-query/ https://github.com/getpop/field-query/): "The syntax described and implemented in this project is a re-imagining of the GraphQL syntax, supporting all the same elements (field arguments, variables, aliases, fragments, directives, etc), however designed to be easy to write, and easy to read and understand, in a single line, so it can be passed as a URL param." I agree with your statement that GraphQL used for meta-scripting should be an anti-pattern. I'm not actually claiming what we should be doing, but what could be achieved if it is led in a proper direction. I actually proposed those 2 extra features for the spec (composable fields and composable directives) which, I believe, would do a great deal concerning this respect. > we see the GET method to do more than 'getting' - sending emails no less! You're right in this remark, but this is just a demo to make it easy to make my point (as I mention in the article, I'm just printing the content on screen, not actually sending the email). In real life, whenever there's a mutation (such as sending an email), then you'd need to execute it via `POST`. But for that same example, just remove one line from that big query (`sendByEmail`) and everything else is idempotent. That's the value of this method.