Pass in slugs to GraphQL relatedTo argument

[dangayle]

We need to be able to pass slugs as arguments in GraphQL requests made using the relatedTo query.

This would be essential for things like having a url /blog/cats that makes a request for a list of blogposts related to the cats category. In this case, you won't know the id, so you would have to make two requests to get the list of categories first just to get the id.

[dangayle]

Initially discussed here: #5071

[andris-sevcenko]

GraphQL basically wraps around Element queries, so this would first have to be implemented in element queries. If this were a twig page, it would still require two separate element queries, right? Of course, there's the difference that it would happen on a single HTTP request, but the point still stands.

So, there are three ways of going forward:

1. do two requests (not optimal, but currently the only way out of the box)
2. implement matching elements by slugs in element queries (feels overkill-y to me, but it's just an opinion)
3. facilitate using the results of a GraphQL query in another GraphQL query in a single request.

My personal favorite is (3). Even though it's not trivial, this seems like the option that offers the most flexibility. But I can't promise it will happen for 3.4.

[narration-sd]

@andris-sevcenko This of course attracted my divergent thoughts tendencies, probably as it models a particular aspect not fully in mind yet about GraphQL.

A couple of things found might be useful to your thinking?

• https://stackoverflow.com/a/47241014 (plus the further answer)
• https://stackoverflow.com/a/54203320/2113528

back to what I'm supposed to be doing...

[denisyilmaz]

Hi @andris-sevcenko, i checked the Changelog in the 3.5 branch to see if this feature will be added there but could not find anything related to this issue here.

Is this feature still planed to be part of 3.5?

[andris-sevcenko]

@denisyilmaz probably not. 3.5 (in terms of GraphQL) will be mainly a mutation-themed release.

This lack of urgency is because there is a way of doing this out of the box by running two queries instead of one (one to fetch ids by slugs, the second one to fetch the relations by ids).

In the long term, I still want to implement the option (3) from the list above as that would add the flexibility of rolling two requests into one.

[denisyilmaz]

@andris-sevcenko thanks for the quick reply. I got this to work in my project the way you described with the two queries. Its working but introduces a delay for page load around 50-100ms depending on server conditions because we have now two roundtrips.

I think this could be resolved when GraphQL Query Batching is working #5677 . any updates on this issue?

EDIT: just realized this is the Option 3 you are talking about, right?

[andris-sevcenko]

Yeah, talking about (3). but I'll see if I can add the batching thing to 3.5!

[andris-sevcenko]

@denisyilmaz Query Batching just takes two queries that are executed in short intervals and combines them into one request. So, given that you can't do the second query before you get the first one back, it won't help you.

As far as the query sequencing (that's the name I'm choosing to call the (3) goes, I've made it happen locally, but it's not part of the GraphQL spec, so, most likely, will happen as a plugin at some point)

[denisyilmaz]

@andris-sevcenko thanks for the clarification. I already guessed this would be not working. But wouldn't it still be easier to extend the entry/entries relatedTo parameter to allow slugs as well? or is this a GraphQL spec as well that only IDs are allowed? I just feel having this sequencing for only getting ids (slug > id > relatedTo(id)) of entries would be something that can happen easier on the server.

In my current project I got it working with to API requests chained after each other. Performance is ok, but still, two requests to get an entry that is related to some other entry where I don't know the ID in runtime this chaining is not a very clean solution.

Still locking forward to Query Batching because then some of the other (unrelated) api-requests might be batched and the Sequencing of the ID would be even less of an issue performance wise.