Skip to content

Commit d0d9523

Browse files
authored
Summarize existing technologies
1 parent 13b8761 commit d0d9523

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

src/pages/blog/2024-04-29-composite-schemas-announcement

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ byline: GraphQL Working Group
77

88
In 2019, Apollo introduced GraphQL Federation as a way of splitting the task of building a GraphQL schema along team boundaries. It proposed a compelling alternative to prior techniques such as schema stitching and delegation, focussing on addressing the collaboration problems inherent in building a coherent schema within a large organization. Federation clearly filled a need and was adopted widely by platform engineers and API developers, a compelling way to compose microservices into a single access layer while retaining service boundaries and team ownership. Solutions from other vendors arose, tackling the same problems in similar ways but with different trade-offs, and some of the world’s largest enterprises have adopted these various patterns and are betting on GraphQL to solve some of their biggest pain points.
99

10-
Adopting this style of collaboration has become a standard way of creating API platforms, with wide support from an array of vendors. Common patterns and best practices have been established around the various implementations and the underlying architecture has proven effective at scale. Today there are many approaches to collaborative GraphQL schema design, requiring different ways of defining the underlying schemas and composing the resulting architecture; for example Federation and Fusion take a … approach, whereas Mesh and Hasura take a … approach. API architects are having to make hard decisions early on in their projects, deciding which of the many patterns to follow.
10+
Adopting this style of collaboration has become a standard way of creating API platforms, with wide support from an array of vendors. Common patterns and best practices have been established around the various implementations and the underlying architecture has proven effective at scale. Today there are many approaches to collaborative GraphQL schema design, requiring different ways of defining the underlying schemas and composing the resulting architecture; for example Federation and Fusion take an approach that optimizes for collaborative schema composition, whereas Mesh and Hasura prioritize flexibility with a variety of heterogenous services or even databases. API architects are having to make hard decisions early on in their projects, deciding which of the many patterns to follow.
1111

1212
Organizations large and small are making huge investments in GraphQL, and those investments are even more sound when they are underwritten by open standards. That’s why the GraphQL Specification Working Group is proud to announce that the Composite Schemas Subcommittee re-convened earlier this year and is making steady progress toward a common specification describing composition and distributed execution across multiple collaborative GraphQL services. The focus is on standardizing common aspects to enable interoperability whilst leaving significant room for innovation so consumers can find the best solution for their needs. Engineers from a wide variety of organizations including Apollo GraphQL, ChilliCream, Google, Graphile, The Guild, Hasura, and IBM have brought their valuable insights to meetings so far; and the community is abuzz with possibilities!
1313

0 commit comments

Comments
 (0)