Scaffold types and queries from DataObject

[chillu]

At the moment there's a lot of boilerplate involved in creating GraphQL types (example). Reduce this by inferring data from DataObjects (where types/queries are based on them).

• Set fields through whitelist
• Infer field types from DBField (String, Text, Enum, etc)
• Field name mapping (see Static case insensitive property check definitions #8)
• Build read queries based on type
• Allow polymorphism based on interfaces (e.g. a createPage mutation which works with all subclasses of Page)
• Build create/update/delete queries
• Build input types for mutation queries
• Custom field resolvers
• Custom query resolvers
• Read queries optionally based on SearchContext definitions
• Register types and queries with a schema manager
• Allow extension of definitions (e.g. whitelist a new field added by DataExtension)

See https://github.com/chillu/silverstripe-graphql/issues/8 for a start on an API.

[chillu]

Some links for @unclecheese:

• https://github.com/larsbs/graysql-orm-loader
• https://github.com/overblog/GraphQLBundle
• https://github.com/goco-inc/graphql-activerecord
• https://github.com/colepatrickturner/graphql-rails-resolver
• https://github.com/4rthem/graphql-mapper
• https://medium.com/the-graphqlhub/graphql-tour-interfaces-and-unions-7dd5be35de0d#.8imiz7f3j
• http://stackoverflow.com/questions/34726666/real-world-example-of-graphqlinterfacetype-and-graphqluniontype
• https://facebook.github.io/graphql/#sec-Inline-Fragments
• https://github.com/charlieschwabacher/gestalt
• Polymorphic input types graphql/graphql-spec#114

[chillu]

I've discussed this a bit more with @unclecheese, and here's some really rough drafts on how this could look like. Overall, we feel that YAML could provide a good result for most use cases, as long as you can write custom resolver classes. These would be injectable, and implement Extension so they can be augmented by third-party code.

GraphQL:
  Member:
    operations:
      - all: true # implies 'create', 'read', 'update', 'delete'
    fields:
      - Email
      - Fullname
      - Groups # Implicitly creates a "Group" GraphQL type
    resolver: MyGraphQLMemberResolver
  Group:
    operations:
      - read: true #only allow reads
    fields:
      Title

class MyGraphQLMemberResolver extends GraphQLResolver {
  public function resolve($args) {
    $list = Member::get();
    // Optional filtering (could be more succinct through SearchContext)
    if($args['Email'])
    $list = $list->filter('Email', $args['Email']);
    return $list;
  }
  // Alternative to accessing DataObject getters
  public function resolveFullname($obj) {
    return $obj->FirstName . ' ' . $obj->LastName;
  }
}

Alternatively, a more fluent API:

$scaffolder = (new GraphQLScaffolder())
    ->addDataObject('Member')
    ->addOperation('Member', GraphQLScaffolder::READ, [])
    ->addFieldResolver('Member', function($args) {
       $list = Member::get();
      // Optional filtering (could be more succinct through SearchContext)
      if($args['Email'])
      $list = $list->filter('Email', $args['Email']);
      return $list;
    })
    ->setFields('Group', ['Title']);

// Get a TypeCreator for further customisation
$memberType = $scaffolder->getType('Member');
// Add all created types, queries and mutations to a schema (through the Manager API)
$scaffolder->addToManager($manager);

I've found an EZSystems configuration which takes a similar approach: https://github.com/bdunogier/ezplatform/blob/graphql/src/BD/EzPlatformGraphQLBundle/Resources/config/services.yml

[unclecheese]

I've created some pseudo code for this. Deliberately rough around the edges, since, in all likelihood it's way off. :) Have a look and let me know if this is what you're thinking:

https://gist.github.com/unclecheese/b56833232f521d9873781a4bc4827a2a

[unclecheese]

Had a chance to work on this over the weekend. Have a look https://github.com/silverstripe/silverstripe-graphql/tree/feature/scaffolding

[sminnee]

Is this done, now? It seems to be mostly done...?

[unclecheese]

It would be hard to make the case that it isn't. :)

[pie6k]

Maybe you could infer types from class to reduce boilerplate. Something like https://github.com/prismake/typegql