414 (Request-URI Too Large) about gatsby-source-prismic-graphql HOT 16 CLOSED

Now with fragment support I was able to shrink your query a lot!

I think most servers have a limit of 2048 bytes so we have to stick with that.

You could also potentially use StaticQuery for things that isn't using variables and get this down to a whopping 850 bytes!

Should I strip whitespace by default in the plugin? query.replace(/\s+/g, ' ')

from gatsby-source-prismic-graphql.

I ran into this issue as well, not sure if this is fixable here, but would be nice if the error was reported correctly. Now with the current examples (are they using 3.0.2 even if the package.json lists 3.0.0-alpha.0 as dependency?) the error message is:

The GraphQL query from /src/templates/Page.tsx failed.

Errors:
Unexpected token < in JSON at position 0

GraphQL request (5:5)
4: prismic {
5: page(uid: $uid, lang: "en-us") {
^
6: title

Even the __graphQL response in graphiQL only says:
"{"errors":[{"message":"Unexpected token < in JSON at position 0","locations":[{"line":3,"column":5}],"path":["prismic","page"]}],"data":{"prismic":{"page":null}}}"

To get the correct error message (414 - Request-URI Too Large) you have to adjust the query and use Prismic's graphiQL instead (https://myrepo.prismic.io/graphql).

from gatsby-source-prismic-graphql.

Can you try the 3.0.0 version of the plugin

from gatsby-source-prismic-graphql.

Getting the same error with 3.0.0-alpha.14

Related?
https://github.com/birkir/gatsby-source-prismic-graphql/blob/master/packages/gatsby-source-prismic-graphql/src/utils/index.ts#L66

from gatsby-source-prismic-graphql.

I just found this in the Prismic docs, seems like the query have to be a GET request:

Important to know: contrary to a classic GraphQL API, you need to use a GET request to query the Prismic GraphQl API.

https://prismic.io/docs/graphql/getting-started/intro-to-the-graphql-api#18_1-a-graphql-api-that-uses-get

Is there another solution to avoid doing long queries? Maybe a way to do multiple queries for a page in Gatsby?

from gatsby-source-prismic-graphql.

Cool, no problem, thanks! Yes seems like Prismic will have have to open for POST queries.

Unfortunately they don't support it yet.

from gatsby-source-prismic-graphql.

Reply from Arnaud Lewis on the Prismic slack:

The graphql feature is still at alpha stage and we didn't implement a workaround for it but we have an idea of an implementation. We'll still go with GET request to get some cache on the CDN side.
In the meantime, I have no solution except downsizing the request for now.

from gatsby-source-prismic-graphql.

Great stuff!

Given that there is a size limit, I think it would be great if the plugin stripped white space automatically.

from gatsby-source-prismic-graphql.

Fragments + Whitespace stripped, I will close this issue for now as it is unsolvable.

Feel free to re-open to ask for tips how to reduce the query size, but consider the following:

1. Use fragments
2. Use StaticQuery for data not needing variables
3. Do you really need all the properties?

from gatsby-source-prismic-graphql.

@kkor this has now been fixed with 3.0.5
Also stripping on the server

from gatsby-source-prismic-graphql.

Til Hamingju for being officially featured by Prismic https://prismic.io/blog/prismic-gatsby-preview-plugin! 🙂
(Maybe consider adding the link to the README?)

I'd like to propose re-opening this issue - even though you cannot solve it on your end - and/or more importantly add a mention of this issue in the README, because it is seriously a major blocker for anyone who plans on using slices (or just abnormally large custom types) in prismic though the GraphQL API.

If you are planning on using 5-10 slices (depending on how big they are) and especially if you're using links to other prismic documents, you're very likely to run into the Request-URI Too Large limit when querying document content in templates. And the bad news is that no amount of fragmenting and minimizing the request is going to get around it and Prismic refused to make any promises as to when they might fix this / tell how high of a priority this was for them.

All the workarounds I've come up with a unideal:

• Splitting your slices into multiple custom types in prismic (e.g. grouping slices based on what documents they are used in, query something based on uid with static queries when possible, ...)
  • Not a real solution: because the more custom types the more bloat you introduce in both prismic document links and graphql queries and undoing this is a pain
• Query the largest slices by using prismic.load to dynamically load the content of the slice outside of the template queries
  • Haven't actually tried this, but as long as you can pass all variables down to the query with the extra slice content, I don't see why this wouldn't work (although now that I think about it, there's a problem with prismic.load in IE11, that's maybe related because it had a similar fix: making the query smaller prevented the primic.load from throwing errors)
  • Impacts end user load times negatively
  • Using static queries to fetch the content of a slice is not possible, because you can't pass variables to those
• Query the some of the slice content in gatsby-node.js in createPages with as many graphQL queries as needed, maybe even split the graphql queries based on the document properties, then pass all data down to templates through the page context
  • Haven't tried this one yet either, but I'm leaning toward this solution, because moving all the queries into gatsby-node will probably give a performance boost to the build times too (currently at 2+ minutes :/): gatsbyjs/gatsby#7373 (comment)
• other ideas are welcome?

from gatsby-source-prismic-graphql.

I ran into this myself the other day and now I'm curious as to how I can inspect the graphql query that is fired off towards Prismic. @ffdead how did you get that URL for the curl command?

from gatsby-source-prismic-graphql.

I ran into this myself the other day and now I'm curious as to how I can inspect the graphql query that is fired off towards Prismic. @ffdead how did you get that URL for the curl command?

@bostrom I think I found it in the networks tab as a failed request (dev tools in Chrome)

from gatsby-source-prismic-graphql.

@ffdead Thanks. Ah, so the query was done live from the browser, not on build time... That makes it easier I guess.

Unfortunately I need to debug it in the build process, so I ended up connecting with Node inspector and drilling down into the depths of this plugin and gatsby itself 😞

from gatsby-source-prismic-graphql.

@ffdead Thanks. Ah, so the query was done live from the browser, not on build time... That makes it easier I guess.

Unfortunately I need to debug it in the build process, so I ended up connecting with Node inspector and drilling down into the depths of this plugin and gatsby itself 😞

@bostrom ah yes, my original problem happened during a preview session

from gatsby-source-prismic-graphql.

Also running into this issue

Wondering if i can do more to fix this. Seems weird to be using a GET request

from gatsby-source-prismic-graphql.