Best practices for multiple queries/query fragments

[lfrancke]

Hi,
I really like the way cynic works, thank you so much for creating it. I'm on 2.2 and have a question on best practices.
I query the GitHub API extensively but a lot of my queries are slightly different (e.g. sometimes I only need two fields from a Repository sometimes a whole bunch of them etc.).

The cynic generator generates Repository, Repository2, Repository3 ... etc. objects out of each of these fragments. And while that works it's not very intuitive (I can't remember which of those three is which).

My question is what you'd say are the best practices in handling these situations.

I can come up with a few possible options:

1. One thing I could do is to treat each query as it's own module and use the generator for each query separately. I could then name the modules semantically: e.g. have a module called repositorymetadata which then has the submodules schema and queries (coming from the generator). That means sharing objects (e.g. PageInfo) would be harder/impossible (at least when using the generator). In addition it means I would have three structs called Repository which makes it harder to use because I probably always need to qualify them to make it easily recognizable which we're talking about:
   `let foo: graphql::repositorymetadata::Repository

2. Or I could keep it all in one big module and name my structs manually (e.g. Repository2 -> RepositoryMetadataOnly).
   This again would mean I can't use the generator easily to recreate stuff.

3. Ignore all of that and just always request the maximum I'll ever need ending up with only a single object. That's not really an option because sometimes I request lots of deeply nested graphs.

I guess it all boils down to more complex use-case not lending themselves very well to the generator but I thought I'd at least ask.
I hope my question makes sense. Thank you!

[Bobrokus]

You can use fragments if they contain the same fields.
However, as of now, it's not possible to include the custom fragment name in the output. I created #1015 to address this problem. Therefore, if you're capturing different fields, I don't know what could help you.

fragment RepositoryMetadataOnly on Repository # or whatever is the type called {
	# fields you want to capture
}

A real-world example I use in practice:

mutation runBulkQuery($query: String!) {
  bulkOperationRunQuery(query: $query) {
    bulkOperation {
      ...BulkOperationFragment
    }
    userErrors {
      ...UserErrorFragment
    }
  }
}

query getCurrentBulkOperationStatus {
  currentBulkOperation {
    ...BulkOperationFragment
  }
}

fragment BulkOperationFragment on BulkOperation {
  errorCode
  fileSize
  id
  objectCount
  partialDataUrl
  status
  type
  url
}

fragment UserErrorFragment on UserError {
  field
  message
}