I have a content-type that heavily uses Slices - it has 8 and counting. I'm also using GraphQL. It would appear once you get to 178 lines in a GraphQL query, it becomes too large and your system rejects it out of hand.
Can you confirm what the size limit is? What is the recommended strategy once this limit is hit? I feel like I'm building in the way Prismic wants me to so I'm surprised I've hit this limit without even double digit slices.
Hi John,
Thanks for reporting this issue, If I understand correctly is the limit here is in the number of lines regardless of how big the response is.
If that is the case can you please provide us with an example of your query to try to reproduce this issue?
Note: You can share this info along with your repository name in a private message if necessary.
Looking forward to your reply,
Fares
Repo:
https://peopleforbikes.prismic.io/graphql
Error message:
"<html>\r\n<head><title>414 Request-URI Too Large</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>414 Request-URI Too Large</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n"
Query that doesn't work:
query LandingPage($uid: String!, $lang: String!) {
landing_page(uid: $uid, lang: $lang) {
_meta {
uid
id
}
title
summary
header_image
main_text
secondary_text
body {
__typename
... on Landing_pageBodyAction_item {
fields {
title
text
extended_text
icon
link {
__typename
... on Basic_page {
parent_page {
__typename
... on Landing_page {
_meta {
id
uid
}
}
}
_meta {
id
uid
}
}
... on _Document {
_meta {
id
uid
type
}
}
... on _ExternalLink {
url
target
}
... on _FileLink {
name
url
}
... on Landing_page {
_meta {
id
uid
}
}
}
}
}
__typename
... on Landing_pageBodyContent_block {
primary {
main_content
}
}
__typename
... on Landing_pageBodyMission_content {
fields {
pillar_title
pillar_content
}
primary {
pillar_title
}
}
__typename
... on Landing_pageBodyAccordion_list {
fields {
accordion_heading
accordion_content
}
}
__typename
... on Landing_pageBodyPromo {
primary {
main_image
top_text
bottom_text
link {
__typename
... on Basic_page {
parent_page {
__typename
... on Landing_page {
_meta {
id
uid
}
}
}
_meta {
id
uid
}
}
... on _Document {
_meta {
id
uid
type
}
}
... on _ExternalLink {
url
target
}
... on _FileLink {
name
url
}
... on Landing_page {
_meta {
id
uid
}
}
}
}
}
__typename
... on Landing_pageBodyResearch {
type
fields {
campaign {
__typename
... on Campaign {
banner_image
small_text
big_text
link {
__typename
... on _ExternalLink {
url
target
}
}
}
}
}
}
... on Landing_pageBodyResearch__reports {
type
fields {
reports {
__typename
... on Report {
title
summary
_meta {
id
uid
type
}
}
}
}
}
}
}
}
Same Query With Fragments (works):
query LandingPage($uid: String!, $lang: String!) {
landing_page(uid: $uid, lang: $lang) {
_meta {
uid
id
}
title
summary
header_image
main_text
secondary_text
body {
__typename
... on Landing_pageBodyAction_item {
fields {
${actionitemSliceFields}
}
}
__typename
... on Landing_pageBodyContent_block {
primary {
main_content
}
}
__typename
... on Landing_pageBodyMission_content {
fields {
pillar_title
pillar_content
}
primary {
pillar_title
}
}
__typename
... on Landing_pageBodyAccordion_list {
fields {
accordion_heading
accordion_content
}
}
__typename
... on Landing_pageBodyPromo {
primary {
${promoSliceFields}
}
}
__typename
... on Landing_pageBodyResearch {
type
fields {
campaign {
__typename
... on Campaign {
banner_image
small_text
big_text
link {
__typename
... on _ExternalLink {
url
target
}
}
}
}
}
}
... on Landing_pageBodyResearch__reports {
type
fields {
reports {
__typename
... on Report {
title
summary
_meta {
id
uid
type
}
}
}
}
}
}
}
}
Solutions:
Inside of my application, I use fragments heavily to get the total size of the query down but even that is starting to fail as my pages get more complex. The biggest offender are these link queries - we have a lot of content-types on our site and they can be referenced all over the place, so the link queries are huge.
There is definitely a ceiling on the query size - do you know what it is?
So i've been able to reproduce this issue, I have done some research and what I understood is the problem comes from the length of Request-URI.
And here is somebody that proposed a workaround for this.
And here is blogpost that explains this workaround in details.
Furthermore I will create an issue in our issue tracker and link this thread to it.
Also I recommend you to check this thread as it seems a related issue.
Prismic preview not working (414 Request-URI Too Large – graphql queries too long)
Best,
Fares
Interesting research Fares. This post on the Apollo site is very illuminating:
In short, they built a tool called persistedgraphql that essentially stores all of this data at the server level:
GitHub - apollographql/persistgraphql: A build tool for GraphQL projects.. That doesn't really work in a serverless world or in a Prismic world I dont think, but an interesting approach.
I think the move it to clean queries as much as possible, maybe reduce whitespace and even run them in a single line, almost like a Webpack graphql reducer plugin. I'll keep noodling on this idea. And post solutions if I develop something custom.
This issue has been closed due to inactivity. Flag to reopen.
I think I found a solution to this @Fares. I did more research into what the reference GraphQL library gives us as developers. They built a really nice function that minifies queries for us:
stripIgnoredCharacters. I implemented it today and it fixed my issue about large query sizes.
Sample implementation below:
// This is a query to get each Page by its uid, so we have to programmatically provide that uid
export async function getSingleLandingPage(uid, previewData) {
const dataCondensed = stripIgnoredCharacters(`
query LandingPage($uid: String!, $lang: String!) {
landing_page(uid: $uid, lang: $lang) {
// do your work here
}
}
`)
// fetch from Prismic with condensed info
const data = await fetchAPI( dataCondensed,
{
previewData,
variables: {
uid,
lang: API_LOCALE,
},
}
)
return data
}
Thank you John for sharing this workaround, very interesting.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
I'm already compressing queries with graphql-query-compress, which certainly helps. But it's not a solution, just a workaround, simply moving the problem a little further away. I still expect to hit the limit again, since I'm still adding new slices to my project and each one makes the query larger.
The only actual solution is going to be to allow POST queries.
Hi @bart,I totally agree that is just a workaround until we allow POST queries and there is already an issue for it.
Yes, like Fares said the team is planning to work on this, but it's not currently being worked on. We'll update you here if/when anything changes.
This is being tracked as an open feature request.
If you have another use-case for this feature, you can 'Flag' this topic to reopen. Please use the 
button to show your support for the feature and check out our Feature Request Guidelines.