Hi,
So it looks like at a certain point you will get a "413 Request Entity Too Large" when using graphQl with a GET request. The URI becomes massive if you have a lot of fragments and in turn slices and eventually you will hit a server limit.
I managed to shave 50% off my URI string by minifying my graphql query strings and stripping out white space etc but i'm worried about the future.
Is there anything that can be done to overcome this?
Hey Freddie,
We are aware of this issue and we’re looking in to ways to combat this when we begin working on improvements for the GraphQL, including potentially allowing POST requests and auto-optimising queries.
For the moment what your doing is good practice and breaking up queries by not going to many levels deep can help.
I’ve logged this as a feature request so the team is aware of how you’re facing issue.
It would help to know more about your use case. Can you tell me more about your queries and what you’re building?
Thanks.
Hi Phil,
Thanks for getting back to me and for getting this higher up the priority.
I can divulge a little more about what it is I’m building yes. I’m building a highly custom website for a client. Right now we have a content type called “static page” which is used for the majority of pages. We also have a lot of slices defined in the static page, such as “Hero”, “Contact Form”, “CTA” etc etc. Our slices are meant to be used so that someone with a non-technical background can add sections ( slices ) to any page and in any order. This should be a pretty standard use case of Prismic correct?
In terms of how things actually work we have Laravel taking the URI e.g “about-page” and then combining that string with a .graphqls file. At a certain point, laravel will load the graphql file and replace $uid with the “about-page” from the URI and then ship this off in a GET request by stuffing everything into a new URI string.
staticpage(uid: "$uid", lang: "en-us") {
prismic_title
page_title
page_description
body {
...Hero
...CTA
}}
$schema = str_replace([
'$type',
'$uid',
], [
$type,
$uid
], (file_get_contents(__DIR__ . '/Prismic/' . $schemaFile . '.graphqls')));
$uri = substr(config('prismic.url'), 0, -7) . '/graphql';
if ($ref === null) {
$ref = json_decode((string)$client->get(config('prismic.url'))->getBody())->refs[0]->ref;
}
$response = json_decode((string)$client->get($uri, [
'headers' => ['prismic-ref' => $ref],
'query' => [
'query' => ($schema)
]])->getBody());
Hope this gives you some insight into how we’re doing things. Above is not the full code but it should demonstrate closely now we are doing things.
Thanks for the extra information Freddie.
This is indeed a standard use case and knowing exactly what your doing and the kind of project structures that are running in to this issue really helps the Dev team to understand the situation better.
I’ve forwarded this to the product team so they can be aware of the situation. If/When they have any update on the situation the will respond to you here.
Thanks.
Hi Phil – as @nathanael and @renaud can attest to, I notified the Prismic team many months ago about this issue on our team’s platinum plan – it exists when using the gatsby-source-prismic-graphql plugin as officially recommended (it does the same as you are, replacing the URL with the preview context inlined).
We have been waiting several months for an update to this issue or a solution, and in the meantime have resorted to creating alternate templates just to hold unique permutations of slices to work around the query length limit. Thankfully most of our pages are compact in length. I’m not sure what we will/would do in the future when we have a super long template with many slices required to be included.
This is also not limited to a preview context, it is a limitation to their graphql API generally. If you have too many slices on a given template type, the request will fail due to data length issues. When I first brought this to the team’s attention, @nathanael and @renaud said they would work on a way to query all slices for a given template in a more compact way, but that also has yet to come to fruition.
This is by far our biggest blocker/issue with the Prismic platform and has been for many months.
Hello @esmith & @freddie.hands,
Our GraphQL API is today relying on GET, so when you fire a request, you're limited by GET constraints. For example, limitations in terms of character. We chose to go with GET for different reasons, mainly caching.
Now, this doesn't solve your issue, and to address them I need to differentiate the two cases.
1 - Eric smith issue
Like @esmith wrote, I'm aware of his use case that is mainly related to the preview in gatsby. From my understanding, this is not something that is blocking the development of the project but only the preview for some pages.
For this problem, We learned a couple of weeks ago that gatsby is deprecating the use of GraphQL API to source data. This approach that they call schema stitching will not be the way to go in the future for them and will prevent your project from having all gatsby new features. It's already the case with Incremental builds that are not supported by the gatsby-source-prismic-graphql plugin.
We will have to provide a transition path to deprecate the usage of this plugin in the future because of this change. This change of plugin will prevent the preview from working in the future. The preview is relying on the fact that we use a graphQL API.
We are working at the moment with Gatsby to see if we will be able to provide a future proof way to query the content through a Rest API and have the preview working at the same time. We will let you know how it goes in the future.
There is still some uncertainty, but it seems clear that this issue will not be solved, and I would recommend that you transition to another gatsby that is not supporting prismic preview fully at the moment. We are preparing a global communication about this topic for the next couple of days.
I would recommend having a look at this plugin GitHub - prismicio/prismic-gatsby: Gatsby plugins for building websites using Prismic that is fitting the guidelines that Gatsby is pushing for. This might be the base of our discussion to support previews in the future.
So my recommendation will be to start the transition to this plugin for now and to follow our discussion about previews.
2 - Freddie Hands issue
I would be interested in having a view at your query if we can do anything to optimize that.
At the moment, there is nothing that we can do to allow more character in the query. That's why i would be interested to see if we can help you optimize that.
For now, I have tracked your remark as a feature request.
At the moment, the internal discussion that we are having that we will have to either accept some predefined fragments to fetch allSlices (this is a solution that we have discussed in the past with @esmith) or to switch our API to accept POST request.
None of these topics have currently been decided in the team and but are scheduled to be worked on in the next weeks.
I hope that helps,
@renaud thanks for the response.
From my understanding, this is not something that is blocking the development of the project but only the preview for some pages.
To be explicit, this issue exists in normal use cases outside of a preview context. It puts a limit on slices per template that is easily achieved if you have developed a moderately sized library of reusable page slices. When we hit this limit, we had to put in place both design and technical workarounds. To call it non-blocking is disingenuous.
I would recommend having a look at this plugin GitHub - prismicio/prismic-gatsby: Gatsby plugins for building websites using Prismic that is fitting the guidelines that Gatsby is pushing for. This might be the base of our discussion to support previews in the future.
Your own blog recommends using the gatsby-source-prismic-graphql plugin to achieve previews using Gatsby, and the support team confirmed this after inspecting our project repository away from the gatsby-source-prismic plugin which we had initially implemented, specifically in order to support previews. This is frustrating news. @Sadek
Hey @esmith,
I understand the frustration and we share it. I think you can understand it because we invested a lot of time in developing/maintaining a plugin that supports preview.
Like I told you this is something that Gatsby changed in their strategy and that is living us no choice than to change our own strategy also.
We are planning communication to share this sad news, but this is something that we learned really recently.
I agree that for a general use case this is blocking and from this point, you can look at the answer that I gave to Freddie.
For your case and all similar cases (Gatsby users), since you are not querying directly our API to build pages, the limitations don’t exist since you’re not querying our GraphQL API directly.
+1 for POST support. Working with Gridsome and many dynamic interactive Slices, you get fast to the max. query lenght of a GET. I think this really needs to have big priority.
+1 on this thread, this has become a major issue for us that we’re having to continuously workaround by using smaller variable names, fragment names, and have to get creative on ways to not add additional fields to our slices or custom types, which is really not ideal. Hoping for a solution soon.
I think it should be possible to use POST to retrieve content from the prismic graphql endpoint. This way you can specify the query in the request body.
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.
This has already been mentioned with regards to issue: https://community.prismic.io/t/graphql-in-post-instead-of-get/2980; and issue 413 Request Entity Too Large - #10 by renaud
I'm too experiencing issues with fragments and query size in apollo graphql and Prismic. A solution to mitigate this is to create the option to query individual slices (e.g by adding the slice id in body_type)
This issue has been closed due to inactivity. Flag to reopen.
Thanks for Great Tool Prismic team.
on my case I'm building a website that allows users to create pages via prismic, so I'm using 1 graphql query with multiple slices for that (dynamic page). I have encountered this issue (413 Request Entity too large), now I am afraid when the client wants a new feature because it will definitely face this error. my team is planning to change it using Rest API instead of Graphql but it will take more time. so may I know when the POST graphql feature will be implemented. Thanks
Hello @muhammad.ilhamsa1, thanks for joining the conversation. We don't have plans to add POST requests to the GraphQL endpoint yet. If we ever do, we'll be sure to make a public announcement on our social media and blog!
I've just stumbled on this roadblock as well.
I've moved from REST to GraphQL due to better content relationship support and now I'm worried about not being able to query for my content with GraphQL as well. 
Some of my queries are already pretty big so maybe I'll have to run one query for each slice to prevent that?