From b54780de377ad7f6d387f23a1c3b8ef6c4c2d9ac Mon Sep 17 00:00:00 2001 From: Praveen Durairaju Date: Mon, 29 Apr 2024 14:24:11 -0700 Subject: [PATCH] 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.