
<p>Netflix is the world’s <a href="https://www.digitaltrends.com/home-theater/most-popular-streaming-services-by-subscribers">most popular streaming service</a>. While everyone knows how it paved the way for a whole new industry when it moved from its physical DVD business to the cloud, you may not know how Netflix’s API platform powered that transition. As Bruce Wang, Director of Engineering of Games Platform at Netflix shared at a <a href="https://www.apollographql.com/events/champions-corner/netflixs-unexpected-journey-to-the-supergraph/">Champions Corner Webinar,</a> they went through four generations of APIs before transitioning to <a href="https://www.apollographql.com/docs/federation/">GraphQL Federation</a>. Read on to learn the many twists and turns of their “unexpected journey” as they broke up their API monolith, used the graph to promote collaboration, manage their tech debt and break down organizational barriers.</p>



<h2 class="wp-block-heading"><a href="#netflixs-api-evolution" aria-hidden="true" class="aal_anchor" id="netflixs-api-evolution"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Netflix’s API evolution</h2>



<h3 class="wp-block-heading"><a href="#act-i-the-beginnings-of-an-api-first-strategy" aria-hidden="true" class="aal_anchor" id="act-i-the-beginnings-of-an-api-first-strategy"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Act I: The beginnings of an API-first strategy</h3>



<p>The year was 2007 — Netflix had amassed 8 million subscribers and 1.25 billion in revenue just ten years after it launched its DVD shipping business. With the rise of bandwidth speeds, the company saw an opportunity to upsend the competition and pivot to online streaming.&nbsp;</p>



<p>It was at this point that Netflix moved onto the cloud and began its API journey. In 2008, development teams built OpenAPI to share Netflix’s growing catalog. “Early on, we were looking at the golden age of APIs where everyone shared their public APIs, and you could then build your experience on top. But by 2011, 99% of the OpenAPI was used for internal consumption.” Bruce shared.</p>



<p>Netflix’s many streaming devices, such as PS3, Xbox, Windows Phone, LG, Roku and others, relied on the REST-based&nbsp; OpenAPI, and Netflix faced challenges supporting user interface agility at a single layer with distributed REST endpoints. To adapt, Netflix created a new API platform, dubbed “API.NEXT” that allowed any UI team to build APIs on top of a single Java-based service layer.&nbsp;</p>



<h3 class="wp-block-heading"><a href="#act-ii-transitioning-to-the-graph" aria-hidden="true" class="aal_anchor" id="act-ii-transitioning-to-the-graph"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Act II: Transitioning to the Graph</h3>



<p>By 2015, Netflix was going to global markets and thousands of devices and form factors, they&nbsp; hit a wall with an oversaturation of lightweight APIs and scripts. The unintended consequence of giving engineers a very flexible API layer was that they created many paths to get data from the backend teams to the frontend applications.</p>



<p>To solve this problem, the company developed a graph language called Falcor, which allowed them to create a single JSON API to pull data. However, this effort at simplification quickly became complex again as the new Falcor API existed side by side with the previous “OpenAPI&#8221; and “API.next.” The obvious next step was to combine all these APIs into a single graph monolith where all clients could access everything they needed from the service layer below.</p>



<h3 class="wp-block-heading"><a href="#act-iii-netflix-studios-rise-spurs-need-for-federated-architecture" aria-hidden="true" class="aal_anchor" id="act-iii-netflix-studios-rise-spurs-need-for-federated-architecture"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Act III: Netflix Studio’s Rise spurs need for federated architecture</h3>



<p>By 2019, Netflix Studio had become one of the biggest production studios in the world. With so much growth, the Netflix Studio team quickly began to feel the pain of their monolithic architecture. They started to explore ways to break apart the API monolith, which included prototyping both a federated graph gateway and a <a href="https://www.infoq.com/presentations/netflix-api-graphql-federation/">GraphQL aggregation layer</a> that would tie all of Netflix’s services together.&nbsp;</p>



<p>Concurrently, Apollo released <a href="https://www.apollographql.com/docs/apollo-server/federation/federation-spec/">Apollo Federation</a>, which offered distributed ownership and subgraph API implementation. Netflix Studio was already using GraphQL, so Federation was the natural next step to support Netflix’s next-generation architecture, Studio Edge.&nbsp;</p>



<p>Studio Edge offered easy discovery and code generation, backend control of schemas, and a single source of truth. It also allowed the API team to focus on key areas of leverage, and platform partners could invest in developer experience, subgraphs, a console UI, and observability.</p>



<h3 class="wp-block-heading"><a href="#netflix-api-the-sequel" aria-hidden="true" class="aal_anchor" id="netflix-api-the-sequel"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Netflix API: The sequel</h3>



<p>By 2021, Netflix had 200 million subscribers, 25 billion in revenue, 25x growth and pivoting toward original, global content. To remain competitive in a market with dozens of new competitors, Netflix launched games and Tudum (a fansite). With these new offerings, it wanted to use lessons learnt from Studio Edge and apply them to the core consumer experience.&nbsp;</p>



<p><strong>“And so then we had a choice,” Bruce said. “We could build on top of our existing system — Falcor — or we could adapt the newest technology that Studio Edge was pioneering. And so this is when we started cultivating a federated experience with different teams that owned individual subgraphs.”</strong></p>



<h2 class="wp-block-heading"><a href="#lessons-learned-in-the-transition-to-the-supergraph" aria-hidden="true" class="aal_anchor" id="lessons-learned-in-the-transition-to-the-supergraph"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Lessons learned in the transition to the supergraph</h2>



<p>One of the main things the company learned during its federation journey is that developer experience is a critical component for both user interfaces and API production. So, how do you invest in the developer experience to set your company up for success?&nbsp;</p>



<h3 class="wp-block-heading"><a href="#lesson-1-learn-how-to-detangle-the-monolith" aria-hidden="true" class="aal_anchor" id="lesson-1-learn-how-to-detangle-the-monolith"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Lesson #1 &#8211; Learn how to detangle the monolith</h3>



<p>Netflix quickly learned that its teams had to build an extremely powerful API layer by being able to leverage GraphQL to stitch older systems and new systems together. “One of the things that we did early on when we started adapting GraphQL, is figure out how do we detangle the monolith,” Bruce highlighted.&nbsp;</p>



<p>Their answer was to create a bridge layer &#8211; pulling out the powerful service layer in the monolith, and then having the new GraphQL layer access the service calls cleanly. Rather than attempting a big bang migration away from its monolith, Apollo Federation allowed them to take a modular approach by combining separate subgraphs for service teams with the agility of the monolith on a supergraph.</p>



<h3 class="wp-block-heading"><a href="#lesson-2-invest-in-the-schema-developer-experience-dx" aria-hidden="true" class="aal_anchor" id="lesson-2-invest-in-the-schema-developer-experience-dx"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Lesson #2 &#8211; Invest in the schema developer experience (DX)&nbsp;</h3>



<p>The second lesson Netflix learned was to invest heavily in schema DX. There are many services involved in the subgraph development model, but the construction of the schema and API product itself is crucial to support developers. Netflix’s ultimate goal was to make collaboration simple, and they learned from previous mistakes that improving&nbsp; schema developer experience makes this possible.&nbsp;</p>



<p>Studio Edge is Netflix’s largest and oldest graph, with 150 subgraphs, 3000 plus types, and 2800 queries and mutations. It&#8217;s a massive graph powering 50-60 internal apps at one time. With the success of Studio Edge and queries from internal partners, Netflix continues to merge APIs using the power of the supergraph.</p>



<h3 class="wp-block-heading"><a href="#lession-3-manage-your-tech-debt-and-organizational-barriers" aria-hidden="true" class="aal_anchor" id="lession-3-manage-your-tech-debt-and-organizational-barriers"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Lession #3 &#8211; Manage your tech debt and organizational barriers</h3>



<p>The truth is that tech debt is inevitable. This means being able to work with your monolith — or whatever system you have — is an asset.&nbsp;</p>



<p>And don’t underestimate organizational barriers, either, Bruce emphasized. GraphQL enables different methods of collaboration between UI teams and backend teams, but it can’t solve fundamental organizational barriers. “Thinking about your product rather than the individual services is a huge, huge win,” Bruce emphasized.</p>



<h2 class="wp-block-heading"><a href="#looking-toward-the-future" aria-hidden="true" class="aal_anchor" id="looking-toward-the-future"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Looking toward the future</h2>



<p>Netflix is operating in a vastly different environment than it was even ten years ago. Streaming has exploded, rights competition is fierce, and hefty new players appear on the market constantly.&nbsp;</p>



<p>So to remain agile, Netflix focuses on the following questions when looking toward the future of its APIs:</p>



<ul class="wp-block-list">
<li>What is the true value of our APIs? </li>



<li>How do we create consistency and resiliency? </li>



<li>How do we make the developer experience excellent?</li>



<li>How do we manage our tech debt? </li>



<li>How do we prepare for challenges with the graph?</li>



<li>How can we use the monolith to our advantage?</li>



<li>What are our own organizational barriers?</li>
</ul>



<p>But above all, Netflix focuses on building an open culture. Bruce said, “You really want to build a learning culture where the main focuses are trusting teams, seeking out excellence, and striving for customer satisfaction. APIs are a journey, and if you can build a learning culture that changes and adapts, you&#8217;ll have a winning formula.”</p>



<h2 class="wp-block-heading"><a href="#conclusion" aria-hidden="true" class="aal_anchor" id="conclusion"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Conclusion</h2>



<p>GraphQL federation allows companies to maintain flexible control of their APIs through subgraphs while scaling their existing systems — resulting in better customer experiences. By learning how to detangle your monolith, invest in the schema developer experience, and manage debt and organizational barriers, Netflix unlocked API success with <a href="https://www.apollographql.com/docs/federation/">Apollo Federation</a>.</p>



<p>You can read more about Netflix’s journey with GraphQL federation <a href="https://www.apollographql.com/blog/redefining-api-strategy-why-netflix-platform-engineering-chose-federated-graphql">here</a>. If you’re ready to go all-in and federate your graphs with Apollo, <a href="https://www.apollographql.com/contact-sales?referrer=nav-contact-sales">contact</a> one of our representatives to get started.</p>


An Unexpected Journey: How Netflix Transitioned to a Federated Supergraph


<figure class="wp-block-image size-large"><img loading="lazy" decoding="async" width="1024" height="573" src="https://wp.apollographql.com/wp-content/uploads/2024/04/API-Days-NY-Apollo-GraphQL-Speakers-1024x573.png" alt="" class="wp-image-23618" srcset="https://wp.apollographql.com/wp-content/uploads/2024/04/API-Days-NY-Apollo-GraphQL-Speakers-1024x573.png 1024w, https://wp.apollographql.com/wp-content/uploads/2024/04/API-Days-NY-Apollo-GraphQL-Speakers-300x168.png 300w, https://wp.apollographql.com/wp-content/uploads/2024/04/API-Days-NY-Apollo-GraphQL-Speakers-768x430.png 768w, https://wp.apollographql.com/wp-content/uploads/2024/04/API-Days-NY-Apollo-GraphQL-Speakers.png 1186w" sizes="(max-width: 1024px) 100vw, 1024px" /></figure>



<p>API Days NY is a must-attend for those looking to network with API leaders and learn how top enterprises are leveraging federated GraphQL in their API platforms. As you can see from the agenda highlights below, it will be an exciting two day event.&nbsp;</p>



<ul class="wp-block-list">
<li>Our founder and CTO, Matt DeBergalis, will share his keynote &#8220;The Year Ahead for GraphQL Federation: Uniting APIs for the AI Era”</li>



<li>API leaders from Netflix, Wayfair and Apollo will present sessions on optimizing performance, creating effective api schemas and building an internal community for effective API governance</li>



<li>Apollo is offering a free workshop to guide you through building your first GraphQL query and beyond</li>



<li><a href="https://bit.ly/43IhuX4">Register to join us for a meetup &amp; happy hour</a> to meet with peer API leaders and GraphQL experts</li>
</ul>



<p>Swing by the Apollo booth to connect, and read on for more details.</p>



<h3 class="wp-block-heading"><a href="#keynote-the-year-ahead-for-graphql-federation-combining-apis-for-the-ai-era" aria-hidden="true" class="aal_anchor" id="keynote-the-year-ahead-for-graphql-federation-combining-apis-for-the-ai-era"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a><strong>Keynote: The Year Ahead for GraphQL Federation: Combining APIs for the AI Era</strong></h3>



<p><em>Matt DeBergalis, Founder and CTO, Apollo GraphQL</em></p>



<p>Forget what you’ve heard about GraphQL – it’s not a REST alternative, graph database, or just for front-end developers. GraphQL is about combining the APIs you already have.</p>



<p>In this talk, you’ll learn how a federated GraphQL architecture brings a platform approach to API composition, where it fits into the API stack, and what is coming next to help teams build tomorrow’s AI products and experiences on today’s APIs.</p>



<h3 class="wp-block-heading"><a href="#session-the-graphql-overhead-myth-or-reality" aria-hidden="true" class="aal_anchor" id="session-the-graphql-overhead-myth-or-reality"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a><strong>Session: The GraphQL Overhead: Myth or Reality?</strong></h3>



<p><em>Marc-André Grioux, Senior Software Engineer &amp; Author, Netflix</em></p>



<p>GraphQL is a powerful tool to enable declarative data fetching on the client and dynamic data representation on the server. This power must have an overhead. In this talk, investigate what this overhead is made of, how impactful it can be to scaling an API platform and services, and how to mitigate it as much as possible while retaining the benefits of GraphQL.</p>



<h3 class="wp-block-heading"><a href="#session-the-secrets-to-graph-success-from-inception-to-general-availability" aria-hidden="true" class="aal_anchor" id="session-the-secrets-to-graph-success-from-inception-to-general-availability"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a><strong>Session: The Secrets to Graph Success, from Inception to General Availability</strong></h3>



<p><em>Leah Hurwich-Adler, Senior Product Leader</em></p>



<p>Building an API platform for a Fortune 100 retailer, capable of handling over 600 million requests per day, requires a highly distributed ecosystem and Federated GraphQL. Drawing from firsthand experience, Leah will share insights on building an internal API community, setting up governance models, and igniting leaders&#8217; enthusiasm for your platform vision. Join this talk to uncover the keys to launching a successful GraphQL platform, through lessons that merge technology with strategic and leadership insights.</p>



<h3 class="wp-block-heading"><a href="#session-benefits-of-idiomatic-code-first-graphql-development" aria-hidden="true" class="aal_anchor" id="session-benefits-of-idiomatic-code-first-graphql-development"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a><strong>Session: Benefits of Idiomatic Code First GraphQL Development</strong></h3>



<p><em>Derek Kuc, Principal Engineer, Apollo GraphQL</em></p>



<p>When building a GraphQL server, two main approaches exist: starting with an SDL and matching resolver logic, or generating the schema directly from code. In this talk, explore the benefits of idiomatic code-first GraphQL development, focusing on GraphQL Kotlin examples. Discover how this approach enhances developer experience and API consistency.</p>



<h3 class="wp-block-heading"><a href="#workshop-build-an-api-composition-layer-with-apollo-graphql" aria-hidden="true" class="aal_anchor" id="workshop-build-an-api-composition-layer-with-apollo-graphql"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a><strong>Workshop: Build an API Composition Layer with Apollo GraphQL</strong></h3>



<p><em>Michael Berger, Solutions Engineer, Apollo GraphQL</em></p>



<p>Use GraphQL to accelerate developer velocity by creating a composition layer for your microservices. Orchestrate data by creating a query that spans your REST APIs and delivers exactly the data your application requires. Learn how to build your first GraphQL query and why GraphQL is valuable to your microservice architecture.</p>



<h3 class="wp-block-heading"><a href="#nyc-meetup-and-happy-hour" aria-hidden="true" class="aal_anchor" id="nyc-meetup-and-happy-hour"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a><strong>NYC Meetup and Happy Hour</strong></h3>



<p><a href="https://bit.ly/43IhuX4">Register to join the Apollo team, Graph Champions, and apidays attendees</a> on April 30 at 6 PM following the conference for bites and beverages at nearby restaurant The Reading Room (16 E 46th St, New York, NY 10017 &#8211; located in the Gotham Hotel)</p>



<h3 class="wp-block-heading"><a href="#still-deciding-get-your-free-pass-now-before-they-run-out" aria-hidden="true" class="aal_anchor" id="still-deciding-get-your-free-pass-now-before-they-run-out"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a><strong>Still deciding? Get your free pass now before they run out!&nbsp;&nbsp;</strong></h3>



<p>The full conference ticket includes access to the Keynotes, Track Sessions, Workshops and Networking Breakfasts and Lunches on April 30 &amp; May 1. Email <a href="mailto:champions@apollographql.com">champions@apollographql.com</a> to learn more and request a pass.</p>


Join Us at API Days in New York City, April 30 & May 1, 2024


<p><em>Highlights of MLB Discussion at API World 2023 conference</em></p>



<p>In the realm of <a href="https://www.mlb.com/">Major League Baseball (MLB)</a>, the quest for excellence extends beyond the playing field. MLB&#8217;s unwavering dedication to a personalized, real-time, media-rich experience for fans deeply connects them to their beloved teams and players. Since the early days of mobile technology, MLB has been a trailblazer with their award winning apps, constantly modernizing its platform&nbsp; to enhance the fan experience. Rob Engel, Vice President of Software Engineering at MLB, unveils the journey of MLB&#8217;s technology transformation in a candid discussion with Dan Boerner, Field CTO, Apollo GraphQL, at the <a href="https://www.youtube.com/watch?v=5DVi99KPALo&amp;t=1184s">API World 2023 conference</a>.&nbsp;</p>



<h2 class="wp-block-heading"><a href="#mlbs-api-challenges" aria-hidden="true" class="aal_anchor" id="mlbs-api-challenges"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>MLB’s API Challenges&nbsp;</h2>



<p>Over a decade ago, MLB faced significant technological challenges with their siloed, batch-oriented XML delivery system for publishing game data to fans and the fan experience suffered.&nbsp;</p>



<p>To address these challenges, Rob and his team recognized the need to modernize their stack. They aimed to build a dynamic API capable of fetching data dynamically from various sources based on incoming requests, starting with the game schedule and expanding to include ticketing prices, video highlights, player insights, and personalized aspects for users&#8217; favorite teams and players. The resulting REST-based Stats API was a huge success, serving over 3 billion daily requests. Yet, its very success led its clients to request additional data, related to game statistics but sourced by completely different teams and underlying services. The Stats API had become an orchestrating monolith, each new feature adding complexity and payload size to what had started as a streamlined single purpose service.&nbsp;</p>



<p>Rob and his team recognized they had reached a new bottleneck and began to search for a more scalable and more performant API architecture. GraphQL stood out as a remedy to the problems of REST over fetching by offering a way for API clients to precisely access only the necessary data, significantly reducing bandwidth usage and accelerating response times. This approach not only enhanced client performance but also contributed to cost savings, avoiding downloading large payloads during frequent scoreboard refreshes.</p>



<p>Beyond runtime efficiency, they also sought a solution to the challenges of ever growing hand stitched service orchestration. How could they get out of the business of being the all things for all clients monolithic orchestration service?&nbsp;</p>



<h2 class="wp-block-heading"><a href="#graphql-and-rest-better-together" aria-hidden="true" class="aal_anchor" id="graphql-and-rest-better-together"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>GraphQL and REST: Better Together&nbsp;</h2>



<p>The answer was nearby &#8212; the content and media side of MLB had been using GraphQL for years and had moved to a federated GraphQL architecture, where teams contribute their domain expertise to a growing superset, a supergraph of API capabilities. But would they face a rewrite of their battle tested, performance tuned Stats API into GraphQL? Not at all, instead, they exposed all the features of their StatsAPI via a new <a href="https://www.apollographql.com/docs/resources/faq/#what-is-graphql">GraphQL</a> subgraph for their growing federated supergraph.&nbsp;</p>



<p>Once the GraphQL resolvers were written, and clients changed their REST API calls to GraphQL queries requesting exactly the data they needed, the <a href="https://www.apollographql.com/docs/router/configuration/telemetry/overview">Apollo Router telemetry</a> began streaming in. Instantly, the Stats team could see which clients needed which data, providing detailed insights into attribute usage. This level of visibility was previously unavailable with REST APIs, and powered better decision-making regarding API optimization, caching and maintenance.&nbsp;</p>



<h3 class="wp-block-heading"><a href="#hitting-a-home-run-with-midfield-graph" aria-hidden="true" class="aal_anchor" id="hitting-a-home-run-with-midfield-graph"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Hitting a Home Run with Midfield Graph</h3>



<p>The GraphQL-based &#8220;midfield&#8221; tier, positioned between the consumer-facing applications (infield) and the microservices (outfield), revolutionized MLB’s data orchestration. This approach streamlined the integration process for various client platforms, facilitated faster onboarding and reduced redundancies in logic implementation.&nbsp;</p>



<figure class="wp-block-image"><img decoding="async" src="https://lh7-us.googleusercontent.com/sWgC1doM0o6vmilHmWpxfh7zZOZtfBpdhbORNoMQvAJTnG5eHN0k_6qCqJOIsg39cnE50ovkCYvvY7Hlh1b85ElGkrFhFKPouAPqaa3BYCE3kBemEYJL7f8ipFWaDVcMtNem3BNoTYqR174W6BuiUdY" alt=""/></figure>



<p><em>Figure 1: MLB’s Midfield Graph</em></p>



<p>The midfield graph layer enabled uniform representation of game-related queries across multiple consumer-facing products, eliminating the need for individual client teams to implement custom logic.</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p><em>“So where [GraphQL] midfield is nice is it moves some of that logic up one level so that the stats team can focus on their domain, which is stats. Ticketing can focus on their domain, which is ticketing, so on and so forth. [&#8230;] So now these teams can really hyper focus on their domain.”</em>&nbsp;</p>
<cite>Rob Engel, VP. of Software Engineering, MLB</cite></blockquote>



<p>Moreover, it addressed intricate scenarios such as &#8220;to be determined&#8221; game schedules, suspended/resumed games, and unknown opponent scenarios without requiring extensive custom coding in the front end.</p>



<blockquote class="wp-block-quote is-layout-flow wp-block-quote-is-layout-flow">
<p><em>“ [Front-end clients] can get it exactly how they want it without having the different teams [&#8230;] have knowledge of each other or creating a problem downstream where all the clients are reimplementing the exact same logic from device to device, from team to team, etc.”</em></p>
<cite>Rob Engel, VP. of Software Engineering, MLB &nbsp;</cite></blockquote>



<p>The graph&#8217;s ability to handle complex business logic, tailored responses, and standardized representations significantly benefited MLB&#8217;s scalability and agility. Notably, the introduction of a personalization aspect through user subgraphs empowered MLB to deliver personalized experiences without overburdening client-side logic. This move towards personalization represents a major business shift enabled by the midfield graph layer. Reflecting on the transition, Rob Engel has stated that the adoption of GraphQL was recognized for enforcing strongly typed data contracts, simplifying documentation, centralizing business logic, and averting sprawls of backend-for-frontend (BFF) solutions. This centralized approach prevented inconsistent data contracts and reduced complexities, offering a streamlined and standardized solution across MLB&#8217;s ecosystem.</p>



<h2 class="wp-block-heading"><a href="#next-steps" aria-hidden="true" class="aal_anchor" id="next-steps"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Next Steps&nbsp;</h2>



<p>Watch the <a href="https://www.apollographql.com/events/tech-talk/graphql-and-rest-true-bffs/">API World 2023 Keynote with MLB</a> to learn more about MLB’s journey to improve their baseball fan experience with GraphQL, reducing data redundancy, optimizing response times, and enhancing overall data accessibility. Want to learn more about why GraphQL and REST are true BFFs, read the “<a href="https://www.apollographql.com/resources/design-a-resilient-api-strategy-with-graphql">Design a Resilient API Strategy with GraphQL</a>” whitepaper today. </p>



<p>Explore other inspiring <a href="https://www.apollographql.com/customers">customer stories</a> and discover how Apollo GraphQL can help future-proof your API strategy.&nbsp;</p>



<p><em>Note: Dan Boerner also contributed to this blog post.&nbsp;</em></p>


MLB’s API Strategy: Hitting a Home Run Transformation with GraphQL Midfield


<p>Volvo Cars is on a journey to have at least 50% of their sales online by 2025. To achieve this goal, the organization needed to create a consistent and intuitive user experience across its website. However, Volvo’s system landscape was so complex that it was taking developers over a week to figure out how to combine APIs into new experiences. To complicate matters further, there were site delays that caused abandonment and shoppers weren’t seeing accurate pricing information or graphics.&nbsp;</p>



<p>In his <a rel="noreferrer noopener" href="https://www.apollographql.com/events/champions-corner/how-volvo-is-building-a-better-digital-car-buying-experience/" target="_blank">Champions Corner webinar</a>, Stephan Lonntorp, Senior Engineering Manager at Volvo Cars,&nbsp;shares how implementing a supergraph with Apollo GraphOS is helping Volvo address these challenges to build a better digital car buying experience that increases online sales.&nbsp;</p>



<h2 class="wp-block-heading"><a href="#struggling-to-scale-with-a-graphql-monolith" aria-hidden="true" class="aal_anchor" id="struggling-to-scale-with-a-graphql-monolith"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a><strong>Struggling to scale with a GraphQL monolith</strong></h2>



<p>When Stephan started on this journey, he began with a GraphQL monolith. He replaced different API gateways with a schema that brought context to the data, abstracting away the complexity of how it&#8217;s pieced together. But, as more teams started using the graph, the monolith strained his team. Changes took a long time to implement and experiences broke daily without warning. (A typical incident being that not every car would show on the website.) </p>



<p>The central graph team was always called to troubleshoot, which meant they couldn’t work on anything else &#8211; even though the incidents were due to underlying systems breaking.</p>



<h2 class="wp-block-heading"><a href="#unlocking-agility-with-the-supergraph" aria-hidden="true" class="aal_anchor" id="unlocking-agility-with-the-supergraph"><svg aria-hidden="true" class="aal_svg" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a><strong>Unlocking agility with the supergraph</strong></h2>



<p>After realizing the monolithic graph wouldn&#8217;t scale, he adopted a supergraph, powered by <a href="https://www.apollographql.com/graphos" target="_blank" rel="noreferrer noopener">Apollo GraphOS</a>, to allow each team to own and manage their data end to end. A new layer in the tech stack, the supergraph unifies all cloud data and services into a single connected map that developers can query with GraphQL.</p>



<figure class="wp-block-pullquote"><blockquote><p><em>We want our entire business on the supergraph because we think it&#8217;s better than those dusty old REST API&#8217;s. We wouldn’t have an accurate online shopping experience without the supergraph.</em> &nbsp;</p><cite>Stephan Lonntorp</cite></blockquote></figure>



<p>GraphOS also delivers visibility into what APIs are being used, so his teams can safely evolve their subgraphs and know who to talk to about potential breaking changes. Today, unplanned breaking changes are fully eliminated.&nbsp;</p>



<p>And, since the supergraph aggregates data from 40 different REST endpoints into one single source of truth, frontend <strong>developers are finding the data they need 99.5% faster.</strong>&nbsp;</p>



<p>The supergraph is also inspiring developers to experiment with the data they now have at their fingertips. Stephan says, “<em>First, you understand what the supergraph is and what it can do for you. Then you realize you can ask for whatever data you want. Just because you’re working on a certain part of the website doesn’t mean you can’t ask for data they’re displaying somewhere else. If you have an idea you can go to the supergraph and start experimenting.</em>”&nbsp;</p>



<p>Stephan was promoted to run engineering for the online fleet sales business and build out its online service offering. Since most of the data they needed was already in the supergraph, they only had to add a few pieces to the business domain supergraph to build the new products.</p>



<figure class="wp-block-pullquote"><blockquote><p><em>Without the supergraph, we’d still be trying to figure out how to build a user journey for&nbsp;the fleet business.</em> </p><cite>Stephan Lonntorp</cite></blockquote></figure>



<p>One new area they built out is company car policies, which enables a fleet manager to set up rules specific to a company and then the car configurator would just show the options allowed by that policy. <strong>They built the initial prototype for that new feature in two and a half weeks</strong>.&nbsp;</p>



<figure class="wp-block-pullquote"><blockquote><p><em>The supergraph is key to achieving our online sales goals because it makes data readily available for&nbsp;developers to use across our website, allowing us to show consistent information throughout the user&nbsp;journey on volvocars.com. At the end of the day, that is what’s going to help us sell more cars.</em>&nbsp;&nbsp;</p><cite>Stephan Lonntorp</cite></blockquote></figure>



<p class="has-large-font-size"><a rel="noreferrer noopener" href="https://www.apollographql.com/events/champions-corner/how-volvo-is-building-a-better-digital-car-buying-experience/" target="_blank">Watch Stephan’s webinar</a> to hear more about Volvo’s journey to improve their digital car buying experience with the supergraph. And, be sure to check out the rest of our <a rel="noreferrer noopener" href="https://www.apollographql.com/events#type=champions-corner" target="_blank">Champions Corner webinars</a><em>.</em></p>


Volvo drives into the future of online car shopping with the supergraph

Part 2 of 2, Best Practices of Schema Governance with the word "governance" crossed out and replaced with "stewardship"

Community

An Unexpected Journey: How Netflix Transitioned to a Federated Supergraph

Join Us at API Days in New York City, April 30 & May 1, 2024

MLB’s API Strategy: Hitting a Home Run Transformation with GraphQL Midfield

Volvo drives into the future of online car shopping with the supergraph

10 Best Practices for Schema Stewardship (Part 2 of 2)

10 Best Practices for Schema Stewardship (Part 1 of 2)

Community

An Unexpected Journey: How Netflix Transitioned to a Federated Supergraph

Join Us at API Days in New York City, April 30 & May 1, 2024

MLB’s API Strategy: Hitting a Home Run Transformation with GraphQL Midfield

Volvo drives into the future of online car shopping with the supergraph

10 Best Practices for Schema Stewardship (Part 2 of 2)

10 Best Practices for Schema Stewardship (Part 1 of 2)

Stay in our orbit