Merge branch 'source' of github.com:YassinEldeeb/graphql.github.io into add-sponsorship-details

Author: YassinEldeeb

src/app/conf/2024/sponsor/index.mdx

@@ -3,7 +3,7 @@ import { Button } from '@/app/conf/_components/button'
 # Sponsor GraphQLConf 2024
 
 <div className="flex flex-row justfiy-center">
-    <Button target="_blank" href="/conf/sponsor/sponsor_2024.pdf" className="!text-white !block">Sponsership Details</Button>
+    <Button target="_blank" href="/conf/sponsor/sponsor_2024.pdf" className="!text-white !block">Sponsorship Details</Button>
     <Button href="mailto:[email protected]?subject=Sponsorships" className="!text-white !block ml-3.5">Contact Us</Button>
 </div>
 Contact us at [email protected] to reserve your sponsorship, ask questions or talk about different options.

src/pages/blog/2024-05-16-composite-schemas-announcement.mdx

@@ -0,0 +1,14 @@
+---
+title: "Announcing the Composite Schemas Working Group"
+tags: ["announcements"]
+date: 2024-05-16
+byline: Jeff Auriemma, Benjie Gillam, Michael Staib, Kamil Kisiela, 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.
+
+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!
+
+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).