4 ms·

Show HN: Nested forEach directive in non-standard GraphQL server

9 points by leoloso 6y ago

dvt 6y ago
> Bringing these additional scripting capabilities to GraphQL, wouldn't it be more valuable than not? I feel that these kinds of proposals will lead to business logic starting to get implemented in GQL queries. And that sounds like a bad idea™.
- bionhoward 6y ago
  Functional directives allow schema-first development, which can be a good idea. Your security rules and graph edges, etc, can live where the data lives. problem is, all the reference implementations lack functional directives...
  - yaacovcr 6y ago
    https://www.graphql-tools.com/docs/schema-directives/#at-least-two-strategies https://www.graphql-tools.com/docs/schema-directives/#at-lea... Not a reference implementation, but built on top of it.
striking 6y ago
In my opinion, I would really prefer that GraphQL stay as simple as it is. It's already very easy to cause performance issues on servers and be forced to work around said performance issues. In your translate example, why not just apply @translate to every field? It's simpler than having to modify the spec to enable it to do something truly magical when the current ability to just fetch data and maybe tag it with some operation or annotation is enough most of the time. Or perhaps it could be contextual, where the user settings / context set the language. Sometimes I wish Facebook hadn't called it GraphQL. Because the "QL" reminds people of SQL, which this very much isn't and shouldn't be. EDIT: I've gone and clicked your link for your proposal for embeddable fields, and found this snippet. mutation { comment(id: 1) { replyToComment(data: data) { id @sendEmail( to: "{{ parentComment.author.email }}", subject: "{{ author.name }} has replied to your comment", content: " On {{ comment.date(format: \"d/m/Y\") }}, {{ author.name }} says: <blockquote>{{ comment.content }}</blockquote> Read online: {{ comment.url }} " ) } } } This is a situation wherein I would really, really, prefer that the client not be doing this work. The server should be doing as much work as possible, so the clients can avoid duplicating logic and requiring workarounds when clients get stuck on old versions that can't be upgraded.
- mdaniel 6y ago
 Also a missed opportunity to get out of quote escape hell, since GQL supports block literals: https://spec.graphql.org/June2018/#StringValue https://spec.graphql.org/June2018/#StringValue (and, irony of ironies, their example is `sendEmail(message: """`) content: """ On {{ comment.date(format: "d/m/Y") }}, {{ author.name }} says: <blockquote>{{ comment.content }}</blockquote> Read online: {{ comment.url }} """
 - leoloso 6y ago
 This is a great idea! If my proposal starts getting support and I get to submit the issue for the spec, I'll certainly include block literals as part of it
- leoloso 6y ago
 This is the reason why I want to support such a query for my GraphQL server: My goal is to allow users of my WordPress plugin (i.e. not just coders, but also non-techies, such as bloggers) to configure how the GraphQL server will behave through a user interface, with no coding involved whatsoever. That query to send email notifications is then a use case all by itself, and a demonstration of what these features can achieve: Using embeddable fields, starting from a `Post`, the UI would enable users to compose the notification message using placeholders `{{ title }}`, `{{ content }}`, `{{ date }}`, etc. With the flat chain syntax it gets better, since they could retrieve data from other entities, such as `{{ author.email }}`, or even iterating down from `Root` doing `{{ root.me.email }}`. Then this string is injected into the directive `@sendEmail` (which would be provided by some WP plugin), and added to the schema through IFTTT rules, as I've described here: https://blog.logrocket.com/adding-directives-schema-code-first-graphql-servers/ https://blog.logrocket.com/adding-directives-schema-code-fir... As a result, the user can install a WP plugin, add `@sendEmail` to the schema through configuration, and customize the email, without touching one line of code.
bionhoward 6y ago
Directives can be extremely powerful, but only if implemented such that custom directives are extremely easy to implement. If I have to wrap one-liner AuthZ functions in 30+ line OOP monstrosities, I’m gonna rage...
- leoloso 6y ago
  I absolutely agree with this. I believe that directives are among GraphQL's most important features, and seeing some servers dealing with them only as an afterthought makes me sad

9 points by leoloso 6y ago

dvt 6y ago

> Bringing these additional scripting capabilities to GraphQL, wouldn't it be more valuable than not? I feel that these kinds of proposals will lead to business logic starting to get implemented in GQL queries. And that sounds like a bad idea™.

bionhoward 6y ago
Functional directives allow schema-first development, which can be a good idea. Your security rules and graph edges, etc, can live where the data lives. problem is, all the reference implementations lack functional directives...
- yaacovcr 6y ago
  https://www.graphql-tools.com/docs/schema-directives/#at-least-two-strategies https://www.graphql-tools.com/docs/schema-directives/#at-lea... Not a reference implementation, but built on top of it.

striking 6y ago

In my opinion, I would really prefer that GraphQL stay as simple as it is. It's already very easy to cause performance issues on servers and be forced to work around said performance issues. In your translate example, why not just apply @translate to every field? It's simpler than having to modify the spec to enable it to do something truly magical when the current ability to just fetch data and maybe tag it with some operation or annotation is enough most of the time. Or perhaps it could be contextual, where the user settings / context set the language. Sometimes I wish Facebook hadn't called it GraphQL. Because the "QL" reminds people of SQL, which this very much isn't and shouldn't be. EDIT: I've gone and clicked your link for your proposal for embeddable fields, and found this snippet. mutation { comment(id: 1) { replyToComment(data: data) { id @sendEmail( to: "{{ parentComment.author.email }}", subject: "{{ author.name }} has replied to your comment", content: " On {{ comment.date(format: \"d/m/Y\") }}, {{ author.name }} says: <blockquote>{{ comment.content }}</blockquote> Read online: {{ comment.url }} " ) } } } This is a situation wherein I would really, really, prefer that the client not be doing this work. The server should be doing as much work as possible, so the clients can avoid duplicating logic and requiring workarounds when clients get stuck on old versions that can't be upgraded.

mdaniel 6y ago
Also a missed opportunity to get out of quote escape hell, since GQL supports block literals: https://spec.graphql.org/June2018/#StringValue https://spec.graphql.org/June2018/#StringValue (and, irony of ironies, their example is `sendEmail(message: """`) content: """ On {{ comment.date(format: "d/m/Y") }}, {{ author.name }} says: <blockquote>{{ comment.content }}</blockquote> Read online: {{ comment.url }} """
- leoloso 6y ago
 This is a great idea! If my proposal starts getting support and I get to submit the issue for the spec, I'll certainly include block literals as part of it
leoloso 6y ago
This is the reason why I want to support such a query for my GraphQL server: My goal is to allow users of my WordPress plugin (i.e. not just coders, but also non-techies, such as bloggers) to configure how the GraphQL server will behave through a user interface, with no coding involved whatsoever. That query to send email notifications is then a use case all by itself, and a demonstration of what these features can achieve: Using embeddable fields, starting from a `Post`, the UI would enable users to compose the notification message using placeholders `{{ title }}`, `{{ content }}`, `{{ date }}`, etc. With the flat chain syntax it gets better, since they could retrieve data from other entities, such as `{{ author.email }}`, or even iterating down from `Root` doing `{{ root.me.email }}`. Then this string is injected into the directive `@sendEmail` (which would be provided by some WP plugin), and added to the schema through IFTTT rules, as I've described here: https://blog.logrocket.com/adding-directives-schema-code-first-graphql-servers/ https://blog.logrocket.com/adding-directives-schema-code-fir... As a result, the user can install a WP plugin, add `@sendEmail` to the schema through configuration, and customize the email, without touching one line of code.

bionhoward 6y ago

Directives can be extremely powerful, but only if implemented such that custom directives are extremely easy to implement. If I have to wrap one-liner AuthZ functions in 30+ line OOP monstrosities, I’m gonna rage...

leoloso 6y ago
I absolutely agree with this. I believe that directives are among GraphQL's most important features, and seeing some servers dealing with them only as an afterthought makes me sad