-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request-URI Too Long #590
Comments
I've noticed this has come up a bit. I'm not 100% sure if something can be done, but I'll take a look at it this weekend and see if I can figure something out. In the meantime if anyone has any suggestions that would be great. |
@Glavin001 At Facebook we solve this problem by storing the query/variable (and maybe response depending on your use case) somewhere locally/on the server and give an ID to access it. Would this be a feasible solution? |
@asiandrummer would what you described be similar to GraphQL Bin's Share functionality: https://github.com/graphcool/graphql-playground#how-does-graphql-bin-work ? I suppose it would work, however is this something builtin to GraphiQL or an external tool you built? |
@asiandrummer Can you please give an example of how this would be done. I am new to the community and would like to implement this. How would you go about storing the query on the server then allowing the client to specify what query it wants? Can you please point me to some documentation or a post that you know of explaining this approach in further detail? |
@michaelcurry Hi there! Basically you would map an unique key to a query string (and probably also variables) and store the combination in the server. There isn't an official documentation as far as I know about this topic since it's one of the advanced topics, but I've found a helpful guide to get you started - https://dev-blog.apollodata.com/persisted-graphql-queries-with-apollo-client-119fd7e6bba5 The above link is closely tied with JavaScript/Apollo tools, but it'd be useful to give you a basic understanding of how a persisted query would be created. Let me know if you have other questions about it please. |
@Glavin001 I think my above comment answered your question, so I'm going to close this issue for now. Feel free to reopen if you disagree please. |
Persisted Queries will work when coupled with an app, such that the queries are known. However, my team's use case may be slightly different. For example, we may have 1 larger query (shared by our team) which tests all fields for a particular model given some variables. The app (e.g. web app with React) itself may support all of these fields, although they are distributed over separate persisted queries. Thus, there exists no persisted query which satisfies the needs of my teammates poking around with GraphiQL. Of course, this example is contrived and may even be against best practices (?). We simply love how easy GraphQL makes it for writing a new query to fit our needs on a case by case basis, and how that can be leveraged for testing/debugging the API. |
@Glavin001 If I understood correctly, an example would be that you just want to play with GraphiQL and share some queries across team members, but you don't necessarily want to create a persisted query, correct? At FB we use persisted queries and another way to share queries around - usually loading by persisted query IDs are good enough, but for testing purposes sometimes we need to share queries that aren't necessarily persisted. We have a way to 1) copy the query/variables/response in an internal wiki-like webpage, 2) create an ID for that (let's call it a text document ID for instance), and 3) load and parse that web-based text document to load queries. I guess we could call it another way to "persist" a query, just not the ones that are being used in an app ;) |
You understand my situation correctly. I will need time to investigate your proposed workaround. Thank you for your support! |
As a thought, perhaps it's useful to try stripping out unnecessary whitespace (if GraphiQL doesn't already). You might end up with quite a few %20s being sent in the URI if the query the user has typed into GraphiQL is nicely indented. |
My team is using GraphiQL and loving it! Thank you for such an awesome tool.
Recently we have been receiving the following error on our longer queries:
I narrowed it down to Apache rejecting the URL:
However, our Infrastructure team will not increase the character count max for Apache stating:
Is there anything we can do to reduce the URL character count? Thanks in advance!
The text was updated successfully, but these errors were encountered: