Composition via Operations

[rajington]

really simple example (please excuse syntax)

pokemon graph:

type Query {
  pokemon(name: String!): Pokemon
}

my graph:

extend type Query {
  pikachu: { pokemon(name: "pikachu") }
}

result:

type Query {
  pikachu: Pokemon
}

I was hoping composing graphs could be as simple as composing components. Apologies if this is too out there, but figured it could be worth an async discussion. I think it makes a lot of sense for the proposals to have inspiration from current directive-heavy composition approaches popularized by many vendors, and indirectly the flatter microservice architectures, but I think they aim to build a single graph and I don't think this is a good goal when considering composition.

I would love to treat graphs closer to scopes and imports from other languages. Directives shouldn't be the basis of composition. It should be as simple as above, but with some directives for translation, manipulation, conforming, etc. purposes only.

[smyrick]

Interesting. First I think we would need to clarify some terms here. In your example, we are still defining GraphQL SCHEMAS that we want to merge not OPERATIONS, which are different artifacts and have different syntax. From that your second example is not valid GraphQL so while we could adopt some new syntax for the GraphQL language and propose that to the core spec, that would most likely not get far as it would slow the process down for the composition-wg. With that in mind I think you are after these key points:

• I want to define schemas and have them merge automatically without extra directives if possible
• We need to follow the core spec and not define some new GraphQL syntax
• We are merging schemas and producing schemas as a result
• I want to be able to extend the root Query type (possibly with aliases?)

Is that correct or are you proposing a composition process that can actually take into account an operation definition without knowing the schema definition and merge those together?

We could merge the first example easier than the second one, it just requires you define both a pokemon resolver and a pikachu resolver:

# Schema1.graphqls
type Query {
   pokemon(name: String): Pokemon
}

type Pokemon {
  name: String
  type: String
}

# ------
# Schema2.graphqls
extend type Query {
  pikachu: Pokemon
}

Merging schema + operations

# Schema1.graphqls
type Query {
   pokemon(name: String): Pokemon
}

type Pokemon {
  name: String
  type: String
}

# ------
# Operation1.graphql
query MyCustomQuery {
  pikachu: pokemon(name: "pikachu") {
    name
  }
}

Are you trying to define hard coded resolvers via aliases?

[rajington]

Are you trying to define hard coded resolvers via aliases?

Yes, that was my goal. If we can define resolvers using operations, then we get very clear composition without any required composition directive support on the composed schemas. I get there's performance concerns with composition in this way, but with caching and gateway visibility I feel things could be optimized similar to language compilers.

Beyond simple resolvers that just forward data, ideally there'd be directives that handle manipulation. For example, if I had a cart that returned me a list of items, I'd be able to define a total resolver that uses some @sum directive, just using GraphQL to define the relationships between various fields and types. I'd like to see the use of these "operation directives" grow to cover most common operations, not just arithmetic but a growing ecosystem of directives like @geocode that returns a standard location type from a string or set of fields that define an address in one system, or @summarize, or just anything that starts making GraphQL not just be about the data, but operations that can be done on data in a (lower level) language-agnostic way.

[smyrick]

Defining resolvers via operation aliases is an interesting idea and could be a fast way to extend a schema. However I don't think you need to know anything about composition to achieve that feature and more importantly I don't think composition should know anything about operation documents. We want to find a way to merge two GraphQL schemas together and what their merged schema looks like.

I see this as a separate proposal of the GraphQL spec that could be brought to the main spec, separate working group, or even some server implementation as a feature.

[rajington]

Thanks, I'll look into that, I agree that makes more sense.

The reason I saw this as an approach to composition is because the operation could operate on a different schema than the one it is extending. It limits what parts of the "subgraph" the supergraph eventually receives, compared to other composition approaches. Ideally the operation itself could apply to the same graph (extend graphql with graphql) and/or one or more remote schemas. Potentially there could be directives to rename, manipulate the data, and even merge the data from multiple these multiple sources.