Comments (13)
Also, as a note, if you don't want to haul the lexer in, a good workaround would be to just do a
.replace(/\s\s+/g, ' ')As the patch mentioned in option 2 above. There'll still be commas and such, but 95% of the character bulk would be cleaned up by just collapsing whitespace to single characters without adding a bunch to the bundle.
Yeah, this trick also works well and can be easy to patch in with createHttpLink.
const httpLink = createHttpLink({
/* ... */
// patch the original fetch
fetch: (url, options) => {
const compressedUrl = url.replace(/(%20)+/g, '%20');
return fetch(compressedUrl, options)
},
})
BTW, only one \s
would be required, since +
means one or more.
Update: have to update \s
to %20
, since it's urlEncoded.
from apollo-feature-requests.
Also, as a note, if you don't want to haul the lexer in, a good workaround would be to just do a
.replace(/\s\s+/g, ' ')
As the patch mentioned in option 2 above. There'll still be commas and such, but 95% of the character bulk would be cleaned up by just collapsing whitespace to single characters without adding a bunch to the bundle.
from apollo-feature-requests.
The first query might be a big query that may exceed some request limitations (happened once with AppSync on AWS). So compression is still preferred.
Sure, but note that useGETForHashedQueries
will use POST for the non-APQ query which hopefully will be fine from a size perspective.
@thekevinbrown Note that your suggestion will cause problems if there are any string literals in your operation which may contain multiple characters! While it's generally best to put strings in variables rather than the operation, it would probably be good to not corrupt operations with string literals. Also @mutoo 's suggestion seems to apply to the entire URL which would include the variables
key too, which also may well have significant spaces.
from apollo-feature-requests.
I have made a fork that uses option 2 that always strips the query string. The fork is available at https://github.com/Jgfrausing/apollo-client and its build can be installed using npm install git+https://github.com/jgfrausing/apollo-client-package.git
.
The changes are the addition of
// src/link/utils/print.ts
import {ASTNode, print as gqlPrint, stripIgnoredCharacters} from 'graphql';
const print = (node: ASTNode): string => {
return stripIgnoredCharacters(gqlPrint(node));
}
export default print;
and replacing all imports of print
from graphql to use the above version of print
instead.
from apollo-feature-requests.
If your server doesn't implement a protocol that allows you to send fixed-size queries that is designed to work well with GET, then it will probably be a challenge to send queries that work well with GET, for sure.
from apollo-feature-requests.
I was looking for update with this PR apollographql/apollo-link#1241
bud found the apollo-link is deprecated.
from apollo-feature-requests.
Our project is using Webpack and node v12+ (module entry support).
Temporarily, we use the NormalModuleReplacementPlugin
to patch this lib:
The webpack config:
resolve: {
mainFields: ['module', 'main'], // make sure module entry at first
},
plugins: [
new webpack.NormalModuleReplacementPlugin(
/\/node_modules\/@apollo\/client\/link\/http\/selectHttpOptionsAndBody\.js/,
path.resolve(process.cwd(), './patch/selectHttpOptionsAndBody.js'),
),
And the patch file:
import { print, stripIgnoredCharacters } from 'graphql';
// ...
if (http.includeQuery)
body.query = stripIgnoredCharacters(print(query));
from apollo-feature-requests.
@jglovier is this something that can be implemented/prioritized?
from apollo-feature-requests.
Ahoy @Jgfrausing! 👋 Thanks for the ping. I'm not involved with work on Apollo Client, so I can't really speak to anything in this thread (both because I'm not familiar with the team's priorities or how this fits into it, and because this is beyond my technical scope of understanding 😄). I'll let someone from the core team respond as soon as they are able.
from apollo-feature-requests.
Automatic persisted queries are a reasonable thing to try here; the persisted query link even takes a useGETForHashedQueries
option that makes it easy to use GET when the link is shrinking the query to a hash and use POST otherwise (eg when it is automatically filling the cache).
from apollo-feature-requests.
Automatic persisted queries are a reasonable thing to try here; the persisted query link even takes a
useGETForHashedQueries
option that makes it easy to use GET when the link is shrinking the query to a hash and use POST otherwise (eg when it is automatically filling the cache).
The first query might be a big query that may exceed some request limitations (happened once with AppSync on AWS). So compression is still preferred.
from apollo-feature-requests.
@glasser what if the server isn't using the apollo server but more generic graphql server implements, I don't think the hashed query would work in this case.
from apollo-feature-requests.
Hi, I keep wondering about this issue from time to time, and felt compelled write something.
I get that automatic persisted queries are a way around the size limitations of GET queries.
I'm also working with a code base where adding support for APQ will require some work.
We're currently using patch-package to get a bit more mileage out of GET and it get's us trough ok for the moment.
Apart from APQ being the alternative here there are some things that I'm wondering about in relation to GET queries:
- GET queries appear to be a supported feature in the sense that
useGETForQueries
exists, and shortening queries is an easy way to get more out of it. It seems that this would be a clear improvement to what can be done with them. - If I understand correctly with APQ the server has to remember the hash sent by the client for the next upcoming request. Wouldn't this open up the server to clients spamming random hashes for queries possibly resulting in the server having to deal with high numbers of hashes that may never be used? In that case the switch to APQ is not just an implementation detail, but something that also implies that runtime memory requirements can easily be different. With GET queries there seems to be a method in place that can already be cached in a CDN without this overhead.
- I'm uncertain about the ways/places where a bigger GET query would cause bigger network traffic. I think that HTTP compression could take care of a lot of it, but am uncertain if that indeed happens, or if there is still a higher cost in network traffic associated to the choice of being more verbose on the network than necessary. If compression doesn't deal with all of the verbosity my impression would be that in both, GET and POST cases the verbosity introduces an additional burden on performance and costs.
TL;DR:
I see that APQ can be an alternative to GET queries in many cases,
but am under the impression that the argument prevents a possible improvement that wouldn't hurt anyone.
from apollo-feature-requests.
Related Issues (20)
- Default onError/onCompleted callback HOT 9
- Automatically infer `__typename` for local data
- Remove React dependency when importing gql from @apollo/client HOT 2
- Support `select` QueryHookOptions in `useQuery`
- @defer timeout in clients HOT 3
- Allow passing in a client object to the `useFragment` hook HOT 2
- Remove "React" from the docs and keep it generic HOT 1
- Support skipToken in useReadQuery HOT 6
- Support for a Cache type policy when field is Garbage Collected HOT 2
- Add cache eviction of a query via query DocumentNode HOT 1
- Run a callback before the internal state of useMutation is updated.
- Local Resolvers: Support returning errors and data together for partial results
- Dependency Dashboard
- Revisit `refetchQueries` API
- Add an option to MockProvider to throw when a request fails to match a mock
- Please add polyfill for `globalThis` as it breaks compatibility for Chrome < v71 HOT 2
- Refetch on window focus HOT 2
- Drop `ApolloClient.query()` in next major HOT 1
- Keyword search in Job postings filter HOT 1
- warnAboutDataLoss fails with stringifying error and breaks application
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from apollo-feature-requests.