feat(server fragments): server predefined fragments

[Ariel-Dayan]

added function addedServerFragments that concats relevent
fragments from the server to req query.
added function findFragments that return relevant fragments
for current request.
added function sliceFirstWord.
added serverFragments option.

resolves #575

[acao]

nice! so we have a standard for this using graphql-config that is used pretty widely for loading additional fragments, for example with playground or graphiql. maybe we can build off of that so folks wont have to maintain duplicate configuration for this and the likely soon to be standard graphql-config?

[acao]

it would be much simpler and more concise to use the graphql visit() function here I think

[acao]

https://graphql.org/graphql-js/language/#visit just parse the operation string to AST, and visit all the FragmentSpread node types i think it would be for this case.

import { visit, print } from 'graphql'

function (serverFragments: string[], query: string) {
   const operationAST = parse(query)
   const serverFragmentString  = ''
   visit(operationAst, {
     FragmentSpread(node) {
      if(serverFragments.includes(node.name.value)) {
          serverFragmentString += print(node)
       }
     }
   })
   return serverFragmentString 
}

[acao]

I could be wrong though, about which option is more performant, as parsing each query and then re-printing the nodes entails another expense, though much of this could be memoized, eventually cached even?

[acao]

EOF issue

[acao]

itll probably be easier and more perfomant to generate this from AST as well

[acao]

also https://travis-ci.org/graphql/express-graphql/jobs/618258347#L236

this is looking good though! i'll gladly help you get it ready for @IvanGoncharov to give this a final pass

as per my earlier comment re: graphql-config, it will make sense as an abstraction around this interface.

[IvanGoncharov]

@Ariel-Dayan @acao Don't want to be a party killer but I don't think it's the right feature for the reference implementation of GraphQL Server.
By supporting incomplete queries (in this case without fragments) we force the entire ecosystem (client tools, graphql gateways, etc.) to do the same.

1. Shorten the query for every client by avoiding to repeat the fragment declaration.

This is solved by persistent queries

Allow the client to have dynamic fragments that are updated server side. For example, if a field was added to the schema server side, the fragment will update accordingly.

It brake assumption for client-side tools they since they were compiled/deployed with different sets of fields and this invalidates GraphQL type-safety/"predictable payload" principle.

At the same time if you want you can add this feature quite easily in your code without modifying express-graphql:

import { parse } from 'graphql';
// ...
app.use(
  '/graphql',
  graphqlHTTP({
    schema: MySessionAwareGraphQLSchema,
    graphiql: true,
    customParseFn(source) {
      const ast = parse(source);
      // code that inject fragments into ast
      const serverFragmentString  = ''
      visit(ast, {
        FragmentSpread(node) {
          const name = node.name.value;
          if(serverFragments.includes(name)) {
            serverFragmentString += serverFragments.get(name);
          }
        }
      });
      
      return concatAST(ast, parse(serverFragmentString));
    }
  }),
);