How to simulate a list of "index" versus "show" in GraphQL?

Question

My data model has two resources: Folderand Messages. Each message belongs to a folder. Sometimes I want to get a list of folders (including some fields for each folder). Sometimes I want to get information about a specific folder (including some fields and messages for this folder).

In Rails / RESTful system, this will correspond to the actions indexand showon the resource Folder; the latter will receive a parameter idthat determines the desired folder. What does this diagram look like in an "idiomatic" graph?

One approach can have one field for each action:

type Query {
  folders: [Folder]
  folder(id: String!): Folder
}

There is some overlap here that seems messy and makes it difficult for the client to analyze and understand the scheme.

Perhaps duplication can be removed with an argument with a null value:

type Query {
  folder(id: String): [Folder]
}

If passed id, only details of this will be returned Folder(as an array of one element). If id- nil, then he will receive details for all folders. This overload seems to add hidden complexity.

Which approach is “best practice”? Is there a better way to simulate this situation?

Answer 1

TL; DR: fields are cheap, use them.

. API REST , , . , :

type Query { folders: [Folder!]! folder(id: String!): Folder }

- folders, null s. - . API , , .

, paginate folders, , , , , .

Answer 2

. , . , .