3 ms·

Show HN: A GraphQL server that executes multiple queries in a single operation

2 points by leoloso 6y ago

leoloso 6y ago
In the link there are a couple of GraphiQL clients. Clicking on the Run button on them, you can play with this functionality, see how the response from "executing multiple queries" is merged, and how the queries can be chained
jarym 6y ago
I absolutely think GraphQL will be the way forward once it evolves a bit further but I have 2 immediate concerns with this: > As we've seen, we could attempt to use GraphQL to execute scripts, including conditional statements and even loops. There's a lot of things many technologies could be made to do but using GraphQL in this manner does not appear particularly readable nor maintainable. I can envisage a more evolved form of GraphQL might appear that looks more elegant for this type of work but as things stand this feels like it should be an anti-pattern. > To run the query, there's no need for GraphiQL: it's URL-based, so it can be executed via GET, and a normal link will do. GET requests are meant to be idempotent but once again we see the GET method to do more than 'getting' - sending emails no less! What happens when web crawlers start hitting that URL? This is a well-established anti-pattern and to have it as an example without warning people of the potential implications is only inviting junior developers to borrow this and make mistakes.
- leoloso 6y ago
  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.

2 points by leoloso 6y ago

In the link there are a couple of GraphiQL clients. Clicking on the Run button on them, you can play with this functionality, see how the response from "executing multiple queries" is merged, and how the queries can be chained

jarym 6y ago

I absolutely think GraphQL will be the way forward once it evolves a bit further but I have 2 immediate concerns with this: > As we've seen, we could attempt to use GraphQL to execute scripts, including conditional statements and even loops. There's a lot of things many technologies could be made to do but using GraphQL in this manner does not appear particularly readable nor maintainable. I can envisage a more evolved form of GraphQL might appear that looks more elegant for this type of work but as things stand this feels like it should be an anti-pattern. > To run the query, there's no need for GraphiQL: it's URL-based, so it can be executed via GET, and a normal link will do. GET requests are meant to be idempotent but once again we see the GET method to do more than 'getting' - sending emails no less! What happens when web crawlers start hitting that URL? This is a well-established anti-pattern and to have it as an example without warning people of the potential implications is only inviting junior developers to borrow this and make mistakes.

leoloso 6y ago
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.