Fork me on GitHub
#graphql
<
2022-03-25
>
steveb8n04:03:36

Q: in Lacinia, using the selections api, is there an idiomatic way to know when union objects are being used in a query? i.e. which union members are present in the selection tree? I can see the keys in the tree but there is no explicit indicator of a union that I can find

steveb8n08:03:35

the reason I ask is because I want to use the sub-set of union types selected to restrict the db query

thumbnail10:03:18

I'm not sure if there's a way; but the list length should be the same, regardless of the selection. i.e. if the collection contains 3 different items, and the client selects 1 of them; the selection should still return 3 types (preferably in the same order as other requests)

steveb8n12:03:44

Interesting. Is that according to the spec? It doesn't make sense to me because that's overfetching which is one of the behaviours graphql is supposed to address isn't it?

thumbnail13:03:13

As far as I know that's according to spec, yes. A selection isn't supposed to work as a filter. If you want a filter you can implement that as a field-argument I suppose.

steveb8n22:03:30

Hmm, in that case I don’t think I agree with the spec. returning data that wasn’t requested seems like a graphql anti-pattern. I’m sure I can dig into the parsed-query data to find the union but then I’m using an unsupported/undocumented api. trying to avoid this.

thumbnail19:03:15

In a sense, the data was actually requested, the client just selected 0 fields in some cases. In order to maintain stability and order guarantees the collection will need to return nils

steveb8n22:03:08

I can see how the spec principles are important but I’m going to prioritise what my api clients need rather that following the spec. seems like GraphQL is all about supporting the client so I don’t feel like I’m violating the design by doing this. in my case, a client wants to request which types to return using union fragments. I can’t think of any downside to supporting this, upside is simpler client code. happy to hear if I am wrong about this assessment

steveb8n22:03:24

your point about ordering is a good one but it is not clear cut because ordering of heterogeneous types only works if they share an interface (not mandatory for unions). seems like a grey area

steveb8n22:03:00

now that I think about this more, I think using a union for a paginated query is not a good api design. instead I need a query root for each type inside the union. I’ll implement that instead. @UHJH8MG6S thanks for pushing me in the right direction

1
thumbnail22:03:53

Good luck with your implementation :)