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?
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.
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.
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.
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.
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.
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.
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
+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.