graphql-platform
graphql-platform copied to clipboard
Allow fusion to merge interface and type of 2 subgraphs
Product
Hot Chocolate
Is your feature request related to a problem?
We have 2 subgraphs-services, maintained by 2 different teams (even inside different companies).
The first subgraph-service is a Product service, which tends to updated quite often. The (simplified) subgraph looks like this:
interface Product {
id: String!
name: String!
}
type FoodProduct implements Product {
id: String!
name: String!
expiryDate: String!
}
type ToolProduct implements Product {
id: String!
name: String!
durabilityRating: Float!
}
type Query {
products: [Product]
productById(id: String!): Product
}
schema {
query: Query
}
The second subgraph-service is a Stock service, which is updated rather seldom. The (simplified) subgraph looks like this:
type Product {
id: String!
inStock: Int!
}
type Query {
products: [Product]
productById(id: String!): Product
}
schema {
query: Query
}
When I right now run theses schemas through fusion, I get the following error:
Unhandled exception: System.InvalidCastException: Unable to cast object of type 'HotChocolate.Skimmed.ObjectType' to type 'HotChocolate.Skimmed.InterfaceType'.
Because on one graph Product is an Interface and the other graph it is a Type.
The solution you'd like
We will need to keep the second subgraph-service Stock service "dumb", which means that it only knows that there are generic products and keeps their stock count. Which means we want to decouple deployments of those 2 services, i.e. when adding on the Product service a new type, e.g.:
type MedicalProduct implements Product {
id: String!
name: String!
requiresPrescription: Boolean!
}
The second Stock service should not require any updates and still be able to return the stock info for the new type as well.
With Apollo Federation we have achieved this so far by using the @interfaceObject directive (see here: https://www.apollographql.com/docs/federation/federated-types/interfaces/) on the second subgraph for Product.
Not sure what the proposed technical solution for fusion could be - maybe something in the schema.extensions.graphql that helps fusion to understand about this use case?
Any further update on this please? Is this possible?