In schema federation the stitches are made not in the gateway service, but in the downstream services.
From HC documentations:
The benefit of this approach is that the domain services define where they extend the Gateway schema. This might first seem odd and you could argue that the domain service should not have any knowledge of the gateway schema. Though in practice many companies see this as a feature rather than a limitation. As the gateway schema grows, the configuration of the schema on the gateway with schema stitching will become more and more complex. A change to a downstream service requires also a change to the gateway. This makes development and also deployment a lot more complex. If teams have sovereignty over different domain services, these teams can work completely independently when you use federations.
In order to do that I have to add the package HotChocolate.Stitching
in all the service:
dotnet add ./graphqlServer package HotChocolate.Stitching --version 12.1.0
dotnet add ./graphqlWarehouse package HotChocolate.Stitching --version 12.1.0
and configure all the downstream service in this way:
// Schema Federation
.InitializeOnStartup()
.PublishSchemaDefinition(c => c
// The name of the schema. This name should be unique
.SetName("inventories")
.AddTypeExtensionsFromFile("./Schema/Stitching.graphql"))
where th Stitching.graphql
is where the extension could be made, eg:
extend type Book implements Node {
availability: [Inventory!]! @delegate(path: "inventoriesByProductId(productId: $fields:id)")
}
In this scenario the gateway service is very dumb, cause it only connects the different downstream services:
builder.Services.AddHttpClient("books", c => c.BaseAddress = new Uri("https://localhost:7059/graphql"));
builder.Services.AddHttpClient("inventories", c => c.BaseAddress = new Uri("https://localhost:7016/graphql"));
builder.Services
.AddLogging()
.AddGraphQLServer()
.AddRemoteSchema("books")
.AddRemoteSchema("inventories")
;