Feature request: strip whitespace from GraphQL queries / fragments / mutations / subscriptions

Currently, when issuing requests to a GraphQL API, the GraphQL string describing the query contains a lot of whitespace. While this makes readability in development mode easier, it is wasteful in production.

Would it be possible to add a function to this library that strips this whitespace away? Here’s some example code that does this:

let graphQLQuery = `...` // some GraphQL literal

graphQLQuery = graphQLQuery
    .replace(/#.*\n/g, '')
    .replace(/[\s|,]*\n+[\s|,]*/g, ' ')
    .replace(/:\s/g, ':')
    .replace(/,\s/g, ',')
    .replace(/\)\s\{/g, '){')
    .replace(/\}\s/g, '}')
    .replace(/\{\s/g, '{')
    .replace(/\s\}/g, '}')
    .replace(/\s\{/g, '{')
    .replace(/\)\s/g, ')')
    .replace(/\(\s/g, '(')
    .replace(/\s\)/g, ')')
    .replace(/\s\(/g, '(')
    .replace(/=\s/g, '=')
    .replace(/\s=/g, '=')
    .replace(/@\s/g, '@')
    .replace(/\s@/g, '@')
    .replace(/\s\$/g, '$')
    .replace(/\s\./g, '.')
    .trim()

This code turns a GraphQL query such as this one:

query SomeQuery($foo: String!, $bar: String) {
  someField(foo: $foo, bar: $bar) {
    a
    b {
      c
      d
    }
  }
} 

into:

query SomeQuery($foo:String!$bar:String){someField(foo:$foo bar:$bar){a b{c d}}}

Preferably this would happen at compile time for a production build, so the GraphQL literals in the source code would be minified in the output bundle and thus sent in minified form to the GraphQL API.

Proposed name for this function: condense.

[IvanGoncharov]

Maybe I am asking this question in the wrong repository though. If so, where should I ask it instead?

@rybon Personally, I think it’s the right place to implement such functionality since minification is tightly coupled with language grammar so it would make sense to keep it together with lexer and parser.

Plus it would be super simple to implement it on top of Lexer and actual implementation should be pretty small.

[IvanGoncharov]

I consider it to be a trivial and obvious feature request, even though the implementation is not.

I totally agree with @rybon it’s not the responsibility of graphql-js to dictate patterns of the client to server communication instead it should provide common functionality as composable building blocks.

Moreover, this functionality is useful in a number of other cases like storing introspection dumps as minified SDL or having a hash function for graphql documents that doesn’t affected by formatting changes.

Please keep this issue on the topic of striping ignored characters and stop discussing best practices for client-server communication.

P.S. Update: I’m working on it ATM with good progress and expect to have it to be ready for review in the next couple days.