Nine sounds generous on the face of it, but with all of the wrapping and grouping Prismic enforces it's actually not possible to query a scalar field on the fourth level of nesting, if the root is an all* query.
I'm trying to build a directory page showing all of the lessons available on an educational site. I have category -< course -< module -< unit. We have fewer than 100 units in total so displaying them all isn't unreasonable in one page and one query, but in graphql following Prismic's recommendation, a unit title's graphql path is:
allCategorys -> edges -> node -> courses -> course -> modules -> module -> units -> unit -> title
That's a query depth of 10, so the query fails. I'm still going to build this page, but I'm now going to have to split the query depth-wise and make more calls, which is inefficient for me and more costly for Prismic.
Would it be possible to reconsider this depth limit? Is a four level hierarchy really too much?
Yes, this is still the way the GraphQL schema in Prismic works. The limit is there in order to protect us from doing too many requests on our side.
So at the moment we are not considering to increase the depth limit of the queries. As you may have guessed, to solve your issue right now, the solution is to split the query into two.
What I can do is mark your thread as an open feature request so we can be aware of it in the future.
I appreciate that’s the reason, but it’s misguided and essentially a false economy. It’d be cheaper for Prismic if I could do this in one request rather than making many requests to get the same information, and a better user experience to boot. Another +1 in the GraphCMS column I’m afraid.
I understand, from that point of view, it is true that it would be useful to have more flexibility within the queries.
We've had discussions about ideas of how to improve the structure of it, but again It’s not something that we have tracked as a future improvement at the moment.
In any case, thanks a lot for the feedback, I'll be sure to add your comments in the feat. request tracker.
Just a thought - A query complexity limit might be better all round than a depth limit - for example expanding _meta object counts against depth but presumably doesn’t increase the cost of servicing the request.
In any case, placing limits on queries to private (access controlled) endpoints serves no real purpose given prismic’s pricing model - it just persuades customers to use more requests, which is free albeit suboptimal for them, and obviously worse for Prismic. Any limits should be set such that a legitimate use case doesn’t hit them.
2 Likes
Pau
closed , flag & select 'Something Else' to reopen.
7
button to show your support for the feature and check out our