Problem
In einem GraphQL-Umfeld, wo es viele verteilte Entwicklungsteams und Services gibt, kann es vorkommen, dass jedes Team versucht, seine eigenen Konventionen durchzusetzen. Das kann dazu führen, dass die einzelnen Clients immer mehr API-Endpunkte anbinden müssen, was einen großen Mehraufwand bedeutet: Konfiguration, Authentifizierung, Maintenance etc.
Lösung
Apollo Federation[1] – eine Architektur, mit der man mehrere GraphQL APIs in einem einzigen Endpunkt vereinen kann.
In einer solchen Architektur gibt es das Konzept von Subgraphen und dem Supergraph. Der Supergraph stellt dabei einen Router bereit, der dafür zuständig ist, eingehende Requests aufzulösen und sie an die entsprechenden Subgraphen weiterzuleiten. Beliebig viele Subgraphen stellen jeweils ein eigenes GraphQL-Schema zur Verfügung, die über einen composition[2] Prozess in ein Supergraph-Schema vereint werden.
Beispiel
type Author {
id: ID!
name: String!
}type Book {
id: ID!
title: String!
}
type Author {
id: ID!
books: [Book]
}type Author {
id: ID!
name: String!
books: [Book]
}
type Book {
id: ID!
title: String!
}Auf der rechten Seite kann man das resultierende Supergraph-Schema sehen, dass nun das einzige Schema aus Client-Sicht ist. Hier wird auch noch ein weiterer Vorteil von Apollo Federation ausgenutzt. Und zwar geht es um das Prinzip von Separation of Concerns. Wie man erkennen kann, hat der Typ Author im Supergraph-Schema ein weiteres Feld books, das gar nicht aus dem Schema vom Author Subgraphen kommt. Über Federation ist es möglich die Funktionalität anderer Subgraphen zu erweitern, um so die Zuständigkeiten der einzelnen Subgraphen besser zu trennen.
