Sylvain Lebresne
Sylvain Lebresne
…e types During composition validation, a path of the supergraph can have multiple valid options in subgraphs due to shared fields. When that happens, this patch validates that the possible...
The context/background for this is explained in details in [this comment](https://github.com/apollographql/federation/issues/2005#issuecomment-1192353960), but the short version is that if an enum type is used as _both_ an input and output type...
We can implement some support for the upcoming [`@defer` graphQL directive](https://github.com/graphql/graphql-spec/pull/742) in the query planner by using entities keys. This will only work for a `@defer` that applies at the...
A supergraph schema is essentially just the "API schema" plus some `join` directives metadata. The "API schema" part can be extracted easily enough with the `Schema#toAPISchema` method. The `join` directives...
Suppose we have the 2 following simple subgraphs: ```graphql # Subgraph S1 type Query { q1(a: A): String } input A { x: Int } ``` and ```graphql # Subgraph...
Apollo studio has recognised a `@contact` directive for a bit that allows to document contact information for subgraph: https://www.apollographql.com/docs/studio/federated-graphs/#subgraph-contact-info. And such directive seems generally useful in the context of federation,...
The main method of `@apollo/subgraph`, the one user mostly care about, is `buildSubgraphSchema`. In federation 2, that method uses the code from the `@apollo/federation-internals` to do most of it's work...
For some reason, we declare `@external` as: ```graphql directive @external(reason: String) on OBJECT | FIELD_DEFINITION ``` but the `OBJECT` location is currently somewhat incorrect here as the code completely ignores...
Currently, defining a key for an entity type is done with: ```graphql type User @key(fields: "id") { id: ID! x: Int y: Int } ``` and this syntax certainly afford...