July 2021 Summaries

Expedia Group, a leading travel company, adopted GraphQL as its graph architecture to simplify the connection layer between their backend capabilities and front-end clients. The graph provided a single point for clients to connect to and for service teams to expose to clients. Adopting GraphQL helped Expedia reduce friction, connections, and coordination points across their boundary layers. They also saw benefits in adopting a strongly typed language, declarative language, and extending common types. However, they faced challenges with schema stitching, including complex gateway code, no way to determine the "true schema" without running the gateway, and preventing conflicts when managing updates. To address these issues, Expedia moved from Schema Stitching to Apollo Federation, which provided a standardized implementation, allowed offline composition and validation of the schema, and changed the coordination across teams. By adopting Federation, Expedia improved performance, reduced latency, and simplified their gateway deployments.

Apollo Workbench is a tool designed to help companies develop their graph using Apollo Federation, reducing the feedback loop time when planning schema changes. It provides features such as composition errors checking, query explain, and mocking designs, allowing developers to work with subgraph schemas directly and understand the overall composition of the design without starting up services or writing code. With Apollo Workbench, teams can create designs from their graphs in Apollo Studio, add operations to designs, view query plans, and mock designs locally for development. The tool is designed to be used with a centralized schema registry, such as Apollo Studio's Rover, and provides insights into graph composition, errors, and query execution plans, enabling developers to work only with subgraph schemas and improve the development experience.

Apollo Server 3 has been released with a modernized codebase designed to serve as a scalable foundation for future development, removing hardcoded dependencies and increasing extensibility. The new version includes several under-the-hood improvements, such as support for the latest versions of Fastify and Hapi, improved error handling, and refreshed documentation. Apollo Sandbox is now suggested as the main tool for querying the server, replacing GraphQL Playground. Future improvements include response-shape-based usage reporting and additional directive support to improve response latency. The community is encouraged to provide feedback on the new version through various channels.

Apollo Federation enables the division of a single GraphQL API's implementation across multiple back-end services, each with its own schema representing different parts of the combined API. A gateway receives incoming queries, splits them among required services, and combines their responses into a single response returned to the client. This setup provides a clean API surface area and helps control data access by limiting each service's data store access. Apollo Federation was adopted for Odyssey to persist users' progress through courses while associating it with the User type from Apollo Studio's GraphQL API. The implementation gives teams separation of concerns, enabling different teams to work on different products and features without interfering with each other. Setting up federation involved creating a local PostgreSQL database, building an Apollo Server, and defining a federated schema using the `buildFederatedSchema` function. Entities were used to extend the User type from the Studio subgraph in the Odyssey subgraph, allowing for controlled access and separation of concerns. The setup also enabled testing queries with `_entities` stubs to avoid running another server locally. With federation, teams can reduce duplication, make changes independently, and improve frontend code by only sending requests to one source.