July 2023 Summaries

Exposing GraphQL subgraphs publicly can lead to serious security breaches due to misconfigured federation, which enables splitting up business logic and improving performance. However, this also opens the door to unauthorized access to sensitive data and capabilities through various means such as direct querying, entity resolvers, or overridden schema fields. To mitigate these threats, it's essential to protect subgraphs at the application level by adding extra layers of authorization, using unique secrets per subgraph, and configuring routers to send headers containing shared secrets to each subgraph. This approach is considered the most consistent and effective way to prevent undesired access to subgraph capabilities, and implementing it immediately is crucial for securing GraphQL microservices.

The design of Propel's GraphQL schema for an analytics API platform involves five key principles: starting with what developers need to build and working backward, writing the docs first, having a low barrier to entry but high ceiling, using specific over general names, and meaningful mutations. These principles aim to simplify the development process while providing flexibility and scalability. The schema design also considers evolving without breaking changes, unions on inputs, modeling analytic metrics in the schema, creating top-level metrics, and leveraging Propel as an analytics backend. By following these principles and examples, developers can create a scalable and maintainable GraphQL schema for their own analytics applications.

The Apollo iOS office hours discussed several topics, including the upcoming support for the @defer directive, which allows clients to communicate with servers that data should be sent back later. Calvin Cestari explained how this directive works and its benefits, while Jeff Auriemma provided context on why it's exciting for Apollo iOS. The team also talked about the performance improvements in Apollo iOS 1.2, including a 15-20% increase in performance, and how they were achieved through changes to data storage and generics. Additionally, Calvin discussed initializers, selection sets, and test mocks, which are related concepts that can help developers generate non-production data for unit tests or previews. The team also touched on the upcoming release of Apple Vision, a new device that combines augmented reality with a camera, and how it might impact the development of Apollo iOS. Throughout the office hours, Calvin and Jeff emphasized the importance of testing and exploring different approaches to achieve the desired functionality.

The maintainers of Apollo Kotlin, a project that uses Gradle as its build tool, have integrated Gradle Enterprise into their workflow to optimize their builds. Gradle Enterprise is a platform that helps boost developer productivity by providing features such as unlimited and automatic build scan invocations, data privacy, cross-build analysis, and failure analytic tools. By integrating the Gradle Enterprise plugin with their `settings.gradle.kts` file, the team was able to enable remote build cache, which reuses the results of previous task executions stored on a remote machine. This significantly reduced their build times, from around 28 minutes to just 4 minutes. The team has also gained confidence and visibility in their build process and is now applying the findings to improve the Apollo Gradle Plugin itself. They are eager to explore further optimizations such as configuration cache and predictive test selection.

The text discusses the challenges of providing real-time data to consumers in modern media apps and how Apollo GraphOS can help solve these issues. It introduces federated subscriptions, a new transport protocol that enables real-time communication between clients and subgraphs without being limited by traditional WebSocket connections. This allows for scalable and resilient real-time APIs, unlocking opportunities for richer experiences and bespoke APIs for external users and third parties. The text also provides guidance on getting started with federated subscriptions, including configuration options and examples, as well as resources for further learning and support.

GraphQL APIs have become essential tools for developers to enhance their applications, but they also invite malicious actors like bots to exploit them through data scraping, spamming, and custom queries. To strike a balance between security and utility, companies need to implement measures to block abusive bots from consuming their GraphQL API while allowing legitimate ones like search engines to scrape their websites. Apollo GraphOS provides an all-in-one solution to build, monitor, and secure GraphQL APIs, including built-in runtime security features that can help protect travel data from malicious bots. By extracting operations from known clients in advance and registering them with Persisted Queries Safelisting, companies can limit the execution of random requests while still allowing developers to craft unique operations. Additionally, using Apollo Router features like Operation Limits and Traffic Shaping allows companies to control the request rate per client and protect their API from scraping attacks.

The benefits of federating a graph with Apollo Federation and Apollo GraphOS include alleviating pain points associated with consolidating data from multiple services behind a single API endpoint, empowering independent teams to own and develop their subgraph independently, and providing the toolsets and controls for well-managed composition of the supergraph. However, despite these benefits, Apollo Federation alone does not provide all the answers when it comes to exposing subsets of the schema to third parties while hiding confidential internal fields. This is where contracts come in, which enable picking and choosing types, fields, and field arguments from the supergraph schema to create multiple different variations of the graph from a single source of truth. Contracts provide logically separated views of the supergraph, removing the need for duplication of effort across teams and preventing inconsistencies between versions. To create contract variants, you can apply the @tag directive in your schema, which allows Apollo Studio to detect fields that should be included or excluded from the new contract variant. The recommended approach is to use an "includes" filter, but both filtering approaches can be used simultaneously depending on the specific use case. Each contract variant requires a separate instance of Apollo Router, and it's possible to manage CI/CD workflows for each contract variant independently with downstream checks to control potential breaking changes. Ultimately, contracts provide a powerful way to manage multiple unrelated logical views of your graph from a single source of truth, making it easier to provide an external API securely and simply with low maintenance overhead.

The travel industry is shifting towards delivering personalized experiences to customers by consolidating data from multiple sources into a unified view. To achieve this, companies are leveraging Apollo GraphOS and Apollo Federation, which offer a solution that combines the benefits of a federated model with the flexibility required for service decomposition. This enables travel companies to maintain a single unified view of their data while still leveraging the advantages of microservice architectures. GraphQL federation allows services to manage dependencies between services, ensuring a complete and accurate customer view. By using federation-specific directives like `@key`, services can mark up their schemas to indicate the fields they depend on or provide to other services, which enables the graph to intelligently track and resolve these dependencies. This results in simplified client logic required to fetch and display user data, such as trip suggestions, with a single request.

A modern media company faces increasing demands for richer and more dynamic web and mobile clients, requiring tailored views of their data and bespoke user inputs. To address this, a supergraph can provide a consolidated view of required data, enabling frontend teams to ship new features faster and reduce performance overheads. A media supergraph exposes a one-stop shop for frontend developers to get the necessary data and rapidly build out new product features as backend teams iteratively expose capabilities in the supergraph schema. By leveraging Apollo GraphOS, media companies can manage relevant portions of their schema independently while providing a consistent experience to end users. The technology enables faster rendering of frontends, omnichannel experiences, managing versions of APIs for third-parties, and real-time data for consumers.

Tushar Bhushan discusses the challenges of integrating third-party providers in the travel industry and introduces Apollo GraphOS as a solution. He explains how traditional GraphQL approaches have limitations when it comes to visibility of individual field usage and clients accessing them, but Apollo GraphOS streamlines this process by leveraging Contracts, demand control features, and field-level metrics. The author highlights the importance of schema contracts, graph variants, and observability tools in creating a seamless and secure integration experience. He also demonstrates how to implement a contract variant using Apollo Federation's `@tag` directive and GraphOS Contracts, which provides several advantages such as maintaining a single source supergraph implementation while serving different applicable versions of the supergraph to different clients.

The text discusses the importance of performance in media companies and how Apollo GraphOS supports rendering frontends faster by using the @defer directive. This feature allows client developers to mark fields in a GraphQL query to indicate which data is critical for immediate user engagement and which can be loaded progressively. The example query shows how to use @defer to load essential movie details immediately while loading other, less critical information like reviews and recommendations in the background. By using this approach, media companies can reduce perceived loading times and create a more seamless user experience, all without needing to manually handle slow data boundaries.

Apollo GraphOS is a technology solution that enables travel companies to build connected apps by providing a singular and consistent API across different devices in the traveler's journey. This allows frontend developers to get the data they need quickly, while backend teams can independently manage relevant portions of a schema with safety. A supergraph-based architecture exposes a one-stop shop for developers to rapidly build new product features as capabilities are iteratively exposed by backend engineering teams. The solution helps power essential features of modern travel services such as shipping products faster, integrating with partners, delivering personalized experiences, and mitigating scraping and bot attacks. By leveraging Apollo GraphOS, travel companies can increase development velocity and ship new features faster, providing a unique opportunity for customers to experience the world in a more meaningful way.

A media organization can create omnichannel experiences by using a federated GraphQL architecture that connects all data sources to a supergraph schema, allowing for a unified API experience across different channels and devices. This approach enables tracking user movements across channels, personalization, and consistent data fetching, resulting in a reliable and enjoyable customer experience. By defining a common Media type with an `id` field and extending it in separate subgraphs, media organizations can create intricate queries that span across multiple subgraphs, such as fetching reviews or comments for a specific piece of media. With Apollo Federation, media companies can simplify their data fetching, break up the larger problem into smaller manageable bits, and let specialized teams own them, resulting in a cohesive and maintainable fashion.

Server-Driven UI (SDUI) is a design pattern that aims to push business logic from the client side to the server, allowing for more efficient and scalable development. By moving business logic to the server, developers can reduce the amount of code on the client-side and make updates easier to manage across multiple apps. This approach requires synchronization between backend and frontend teams but can lead to a better experience for users as it adapts to their needs throughout their journey. The use of GraphQL and Server-Driven UI enables developers to control what components are used, in what order they are rendered, and to make updates immediately without requiring coordination across multiple teams or code bases.

The Apollo Router offers three customization options for adjusting behavior: configuration options, Rhai scripting, and external coprocessing. These extensibility options are crucial for performance and serve as the entry point to a supergraph. A study was conducted to understand the performance implications of these options. The results showed that when possible, configuration options perform better than Rhai scripts, which in turn perform better than external coprocessing. External coprocessing adds around 350μs of overhead per stage, regardless of programming language or complexity. However, the choice of programming language and network proximity can significantly impact performance. It is recommended to use SubgraphRequest/Response stages judiciously, as their overhead can add up quickly. The study also highlighted the importance of considering runtime and networking setup when selecting a coprocessor.