HTTP GET for fetching?

If my understanding were correct, Apollo always uses HTTP POST to fetch the data. Unfortunately it becomes more challenging to cache since many Varnish based solutions cache GET request only (https://www.fastly.com/blog/api-caching-part-i & http://stackoverflow.com/questions/31539043/how-to-cache-post-requests-with-varnish)

  public fetchFromRemoteEndpoint({
    request,
    options,
  }: RequestAndOptions): Promise<IResponse> {
    return fetch(this._uri, assign({}, this._opts, {
      body: JSON.stringify(printRequest(request)),
      method: 'POST',
    }, options, {
      headers: assign({}, {
        Accept: '*/*',
        'Content-Type': 'application/json',
      }, options.headers),
    }));
  };

Is it possible to change this to HTTP GET? If not, what would be best way to do server side edge caching on Apollo/GraphQL?

[bgentry]

Most GraphQL endpoints, FB included, will contextualised their responses depending of the authenticated user.

So does basically every authenticated API. That does not eliminate the value or desire to cache responses. Applications using GraphQL would still benefit from ETag caching which could drastically reduce the amount of unchanged data that needs to be transferred across the wire when re-fetching data. There’s some good background on how that technology works in this Heroku Dev Center article.

It should be up to the server to determine if and when resources can be cached by downstream clients (and to opt into performance enhancements like ETag). The server (along with any intermediaries like caching proxies, CDNs, etc) is still responsible for ensuring that caches respect any authentication headers or cookies, and for making sure that query params are respected as part of cache keys.

By using POST instead of GET for idempotent, read-only requests, you’re merely preventing servers from being able to opt into the performance benefits that caching offers.

The simplest change to support this in apollo-client would just be to tweak the network interface to use GET if a query (not mutation) is being performed. If you’re primarily concerned about compatibility with existing clients, then you could make this an option. But there’s really no reason for it not to be the default.

[bgentry]

This section on the GraphQL docs explicitly states that GraphQL HTTP servers should handle HTTP GET and POST methods.

It seems like a good GraphQL client should use GET whenever possible in order to convey intent for safe/non-modifying queries, and to enable caching by intermediaries. Ultimately it would be great if servers supported Etags and Cache-Control headers to fully take advantage of this.

POST should only be used if the query is too long for a GET request (per-browser limits here) or if the request contains mutations.