From 13b87615a71b7fbd3a3c0b1684606e6011acf0e6 Mon Sep 17 00:00:00 2001 From: Jeff Auriemma Date: Thu, 25 Apr 2024 14:49:04 -0400 Subject: [PATCH 1/9] Composite Schemas Announcement blog post --- .../blog/2024-04-29-composite-schemas-announcement | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 src/pages/blog/2024-04-29-composite-schemas-announcement diff --git a/src/pages/blog/2024-04-29-composite-schemas-announcement b/src/pages/blog/2024-04-29-composite-schemas-announcement new file mode 100644 index 0000000000..229269b3a4 --- /dev/null +++ b/src/pages/blog/2024-04-29-composite-schemas-announcement @@ -0,0 +1,14 @@ +--- +title: "Announcing the Composite Schemas Working Group" +tags: ["announcements"] +date: 2024-04-29 +byline: GraphQL Working Group +--- + +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. + +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. + +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! + +As with any GraphQL Working Group, anyone is welcome to join and contribute! To get involved, add yourself to an [upcoming agenda](https://github.com/graphql/composite-schemas-wg/tree/main/agendas) or watch all former meetings on the [official YouTube channel](https://www.youtube.com/playlist?list=PLP1igyLx8foFjxyTg6wPn4pUkZwuAk2GR). From d0d95236e09eb559ddd83ed90f50dffc13ce1237 Mon Sep 17 00:00:00 2001 From: Jeff Auriemma Date: Fri, 26 Apr 2024 12:38:34 -0400 Subject: [PATCH 2/9] Summarize existing technologies --- src/pages/blog/2024-04-29-composite-schemas-announcement | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/blog/2024-04-29-composite-schemas-announcement b/src/pages/blog/2024-04-29-composite-schemas-announcement index 229269b3a4..fb2e6e9e6c 100644 --- a/src/pages/blog/2024-04-29-composite-schemas-announcement +++ b/src/pages/blog/2024-04-29-composite-schemas-announcement @@ -7,7 +7,7 @@ byline: GraphQL Working Group 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. -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. +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. 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! From c9a5f4c4d3645d04b8a47afe062f255362712f81 Mon Sep 17 00:00:00 2001 From: Jeff Auriemma Date: Fri, 26 Apr 2024 12:38:58 -0400 Subject: [PATCH 3/9] Update extension --- ...announcement => 2024-04-29-composite-schemas-announcement.mdx} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename src/pages/blog/{2024-04-29-composite-schemas-announcement => 2024-04-29-composite-schemas-announcement.mdx} (100%) diff --git a/src/pages/blog/2024-04-29-composite-schemas-announcement b/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx similarity index 100% rename from src/pages/blog/2024-04-29-composite-schemas-announcement rename to src/pages/blog/2024-04-29-composite-schemas-announcement.mdx From 7cb5cc2660e787895c1367819bb72eaded1935ec Mon Sep 17 00:00:00 2001 From: Jeff Auriemma Date: Fri, 26 Apr 2024 12:49:06 -0400 Subject: [PATCH 4/9] Add authors --- src/pages/blog/2024-04-29-composite-schemas-announcement.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx b/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx index fb2e6e9e6c..0b1fac4de4 100644 --- a/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx +++ b/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx @@ -2,7 +2,7 @@ title: "Announcing the Composite Schemas Working Group" tags: ["announcements"] date: 2024-04-29 -byline: GraphQL Working Group +byline: Jeff Auriemma, Benjie Gillam --- 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. From 33bfb1c7653a0a41d765cdbdf08818ba341b53c9 Mon Sep 17 00:00:00 2001 From: Michael Staib Date: Mon, 29 Apr 2024 18:49:28 +0200 Subject: [PATCH 5/9] Added Michael Staib --- src/pages/blog/2024-04-29-composite-schemas-announcement.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx b/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx index 0b1fac4de4..8f356dec74 100644 --- a/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx +++ b/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx @@ -2,7 +2,7 @@ title: "Announcing the Composite Schemas Working Group" tags: ["announcements"] date: 2024-04-29 -byline: Jeff Auriemma, Benjie Gillam +byline: Jeff Auriemma, Benjie Gillam, Michael Staib --- 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. From b54780de377ad7f6d387f23a1c3b8ef6c4c2d9ac Mon Sep 17 00:00:00 2001 From: Praveen Durairaju Date: Mon, 29 Apr 2024 14:24:11 -0700 Subject: [PATCH 6/9] add Praveen to byline --- src/pages/blog/2024-04-29-composite-schemas-announcement.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx b/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx index 8f356dec74..2645a78c18 100644 --- a/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx +++ b/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx @@ -2,7 +2,7 @@ title: "Announcing the Composite Schemas Working Group" tags: ["announcements"] date: 2024-04-29 -byline: Jeff Auriemma, Benjie Gillam, Michael Staib +byline: Jeff Auriemma, Benjie Gillam, Michael Staib, Praveen Durairaju --- 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. From 8dc7eb4f246d5f82763bc68b188f7000e629c154 Mon Sep 17 00:00:00 2001 From: Benjie Date: Tue, 30 Apr 2024 10:13:03 +0100 Subject: [PATCH 7/9] Update src/pages/blog/2024-04-29-composite-schemas-announcement.mdx Co-authored-by: Kamil Kisiela --- src/pages/blog/2024-04-29-composite-schemas-announcement.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx b/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx index 8f356dec74..2f1406616e 100644 --- a/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx +++ b/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx @@ -2,7 +2,7 @@ title: "Announcing the Composite Schemas Working Group" tags: ["announcements"] date: 2024-04-29 -byline: Jeff Auriemma, Benjie Gillam, Michael Staib +byline: Jeff Auriemma, Benjie Gillam, Michael Staib, Kamil Kisiela --- 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. From f894ab9dc2f22722b4e784d3c7d7c169d3a52bdf Mon Sep 17 00:00:00 2001 From: Benjie Date: Thu, 16 May 2024 17:21:01 +0100 Subject: [PATCH 8/9] Update date --- src/pages/blog/2024-04-29-composite-schemas-announcement.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx b/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx index 03036e3676..0b6949ae76 100644 --- a/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx +++ b/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx @@ -1,7 +1,7 @@ --- title: "Announcing the Composite Schemas Working Group" tags: ["announcements"] -date: 2024-04-29 +date: 2024-05-16 byline: Jeff Auriemma, Benjie Gillam, Michael Staib, Kamil Kisiela, Praveen Durairaju --- From 911c956ea9ba818f7e1631957213658714d77d76 Mon Sep 17 00:00:00 2001 From: Benjie Date: Thu, 16 May 2024 17:21:39 +0100 Subject: [PATCH 9/9] Rename to reflect date --- ...uncement.mdx => 2024-05-16-composite-schemas-announcement.mdx} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename src/pages/blog/{2024-04-29-composite-schemas-announcement.mdx => 2024-05-16-composite-schemas-announcement.mdx} (100%) diff --git a/src/pages/blog/2024-04-29-composite-schemas-announcement.mdx b/src/pages/blog/2024-05-16-composite-schemas-announcement.mdx similarity index 100% rename from src/pages/blog/2024-04-29-composite-schemas-announcement.mdx rename to src/pages/blog/2024-05-16-composite-schemas-announcement.mdx