Proposal for "Embeddable fields" in GraphQL

[leoloso]

https://leoloso.com/posts/proposal-for-embeddable-fields-in-graphql-query/

[leoloso]

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_fo...

Please be welcome to give your feedback, here on HN or there on Reddit.

Thanks

[alexchamberlain → leoloso]

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

[leoloso → alexchamberlain]

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-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.

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|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-featur...

I've also proposed composable fields for the GraphQL spec (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)

[adamredwoods]

I would say this is what your resolvers are for.

Also, how would this effect the schema? Description would be a string, but where do we define title and date? Must they be within the same data source? What if they're not?

I think Graphql wants to be as simple as possible.

[leoloso → adamredwoods]

Yep, `title` and `date` are also fields on the same type `Post`. You could do this too:

```

query {

  posts {

    desc: echo(value: "{{ title }} with {{ date }}")

    title

    date
  }

}

```

If those fields are not there, then it will give an error. I added a section about this on my proposal, under section "Further research":

https://leoloso.com/posts/proposal-for-embeddable-fields-in-...