title: graphql organization: put 'actions' into nested type to reduce/group entry points?
body: <p>I've read about different ways to organize graphql queries. 
  Most seem to show a query/mutation for each different action. </p>
  
  <p>i.e. </p>
  
  <pre class="lang-js prettyprint-override"><code>@Query('getComment')
  async getComment() {
    ...
    return comment;
  }
  @Query('getComments')
  async getComments() {
    ...
    return comments;
  }
  @Query('getCommentByID')
  async getCommentById(id) {
    ...
    return comment;
  }
  </code></pre>
  
  
  
  <p>After adding all the different permutations, I have a lot of queries and mutations. </p>
  
  <p>Other sources suggest to keep entry points to the graph minimal. 
  After some experimentation I have: </p>
  
  <pre class="lang-js prettyprint-override"><code>// schema
  type Query {
    comment: CommentActions
  }
  
  type CommentActions {
    getCommentByID(id: ID!): Comment
    getAllComments(): [Comment]
    getComments(): [Comment]
      ...
      // etc
  }
  </code></pre>
  
  
  
  <p>then in my resolver (this example in NestJS/apollo) </p>
  
  <pre class="lang-js prettyprint-override"><code>@Query('comment')
  async getComment(): Promise &lt; CommentActions &gt; {
    return new CommentActions();
  }
  
  @ResolveProperty('getAllComments')
  async getAllComments(@Parent() comment) {
    // ...
    return comments;
  }
  
  @ResolveProperty('getCommentById')
  async getAllComments(@Parent() comment, @Args('id')) {
    // ...
    return comment;
  }
  // etc
  </code></pre>
  
  
  
  <p>Query variations are essentially moved to field resolvers. This POC works fine technically (querying the graph without issue).  </p>
  
  <p>A query example looks like:</p>
  
  <pre class="lang-js prettyprint-override"><code>query {
     comment {
      getAllComments {
        id
      }
    }
  }
  </code></pre>
  
  
  
  <p>I like this because it means in the published graph schema (e.g in gql playground), things can be grouped more easily, and each entity only has a single entry point. </p>
  
  <p>Are there flaws to this approach? 
  Is it 'ok' but not a very 'graphql' way to do things: I worry I'm inadvertently forcing a REST like model where it doesn't fit. </p>
  
  <p>Are there issues or other tasks which will become much more difficult and/or impossible as schema gets more complex? </p>
  
  <p>Any/all feedback, insight or suggestions for alternative structure greatly appreciated.   </p>