3 ms·

Hey everyone, I've added support to what I call "embeddable fields" on my GraphQL server: ``` query { posts { description: echo(value: "Post {{title}} wa

Hey everyone, I've added support to what I call "embeddable fields" on my GraphQL server: ``` query { posts { description: echo(value: "Post {{title}} was published on {{date}}") } } ``` I'm currently trying to find out if the GraphQL community would benefit from this feature. If so, I'll propose it for the spec, but as an optional (similar to cursor connections). I've written a long post describing this new feature, which is the link I've shared. I've also started a discussion on /r/graphql: https://www.reddit.com/r/graphql/comments/j043rw/proposal_for_embeddable_fields_in_graphql/ https://www.reddit.com/r/graphql/comments/j043rw/proposal_fo... Please be welcome to give your feedback, here on HN or there on Reddit. Thanks

alexchamberlain 6y ago
Have you considered combining the GraphQL query with some form of transform query server side instead? Maybe something like `jq`?
- leoloso 6y ago
  You mean a filter to transform the query from A (say, with syntactic sugar syntax) to B (with final syntax)? I'm actually doing something similar in GraphQL by PoP, on a couple of levels: queries are decoupled into requested and executable, where they can differ in syntax, directives attached to them, and others. I wrote a bit about this strategy here: https://blog.logrocket.com/adding-directives-schema-code-first-graphql-servers/ https://blog.logrocket.com/adding-directives-schema-code-fir... In addition, GraphQL by PoP does not understand the GraphQL syntax. It understands another syntax, that I've called PQL: https://graphql-by-pop.com/docs/extended/pql.html https://graphql-by-pop.com/docs/extended/pql.html. PQL is a superset of the GraphQL query, so GraphQL by PoP transforms from GraphQL to PQL syntax and then executes it. For instance, this GraphQL query: ``` query { posts { excerpt titleES: title @translate(from:"en",to:"en") } } ``` is converted to this: ``` posts.excerpt|title@titleES<translate(from:en,to:es)> ``` Check it out here: https://newapi.getpop.org/api/graphql/?query=posts.excerpt|title@titleES%3Ctranslate(from:en,to:es)%3E https://newapi.getpop.org/api/graphql/?query=posts.excerpt|t... This works great. Only issue is when there's some error when retrieving the data, and I need to return an error message with the path to the problem in the query. In that case, the path corresponds to the transformed PQL query, not the original GraphQL query. (It would be possible to have a mapping for them, token by token, but I haven't coded it) --- Btw, connected to PQL, GraphQL by PoP can support the embeddable fields feature because the PQL supports composable fields, which can be considered its superset: https://graphql-by-pop.com/docs/extended/pql-language-features.html#composable-fields https://graphql-by-pop.com/docs/extended/pql-language-featur... I've also proposed composable fields for the GraphQL spec (https://github.com/graphql/graphql-spec/issues/682 https://github.com/graphql/graphql-spec/issues/682) but it hasn't got any support (that's why I'm now asking if embeddable fields could have some backing)

alexchamberlain 6y ago

Have you considered combining the GraphQL query with some form of transform query server side instead? Maybe something like `jq`?

leoloso 6y ago
You mean a filter to transform the query from A (say, with syntactic sugar syntax) to B (with final syntax)? I'm actually doing something similar in GraphQL by PoP, on a couple of levels: queries are decoupled into requested and executable, where they can differ in syntax, directives attached to them, and others. I wrote a bit about this strategy here: https://blog.logrocket.com/adding-directives-schema-code-first-graphql-servers/ https://blog.logrocket.com/adding-directives-schema-code-fir... In addition, GraphQL by PoP does not understand the GraphQL syntax. It understands another syntax, that I've called PQL: https://graphql-by-pop.com/docs/extended/pql.html https://graphql-by-pop.com/docs/extended/pql.html. PQL is a superset of the GraphQL query, so GraphQL by PoP transforms from GraphQL to PQL syntax and then executes it. For instance, this GraphQL query: ``` query { posts { excerpt titleES: title @translate(from:"en",to:"en") } } ``` is converted to this: ``` posts.excerpt|title@titleES<translate(from:en,to:es)> ``` Check it out here: https://newapi.getpop.org/api/graphql/?query=posts.excerpt|title@titleES%3Ctranslate(from:en,to:es)%3E https://newapi.getpop.org/api/graphql/?query=posts.excerpt|t... This works great. Only issue is when there's some error when retrieving the data, and I need to return an error message with the path to the problem in the query. In that case, the path corresponds to the transformed PQL query, not the original GraphQL query. (It would be possible to have a mapping for them, token by token, but I haven't coded it) --- Btw, connected to PQL, GraphQL by PoP can support the embeddable fields feature because the PQL supports composable fields, which can be considered its superset: https://graphql-by-pop.com/docs/extended/pql-language-features.html#composable-fields https://graphql-by-pop.com/docs/extended/pql-language-featur... I've also proposed composable fields for the GraphQL spec (https://github.com/graphql/graphql-spec/issues/682 https://github.com/graphql/graphql-spec/issues/682) but it hasn't got any support (that's why I'm now asking if embeddable fields could have some backing)