October 2023 Summaries

Apollo is releasing a new insights dashboard in GraphOS Studio, providing scalable observability tools to API owners operating a supergraph. This new experience offers a consolidated and streamlined approach for accessing operation and field insights, with fast and intuitive search capabilities, filterable lists, and improved load times for large graphs. The new insights experience is now available for all GraphOS users, allowing them to get started by navigating to Insights in the left navigation.

The official Apollo Federation support library for Hot Chocolate, a popular .NET GraphQL framework, has been released with full Federation 2 support. This allows developers to create subgraphs that expose API services as a single GraphQL access layer, enabling modular and scalable architecture. The new library provides annotation-based Federation for clean idiomatic C# code, GitHub actions configured for CI/CD using GraphOS schema checks and publishing, and one-click deploy templates with Railway. It also includes comprehensive support for field migrations, entity interfaces, and flexible type ownership. With this release, Apollo continues to maintain official Federation subgraph support for Hot Chocolate, planning ongoing improvements and fixes, as well as full support for the latest Apollo Federation spec changes.

GraphOS Persisted Queries are a scalable solution to mitigate the risks of unbounded operations in supergraphs by centrally registering trusted GraphQL operations and safelisting them, allowing platform teams to limit the attack surface area while empowering frontend and backend teams to consume and build services independently.

The curl project has released details regarding CVE-2023-38545, a high-severity vulnerability found in curl and libcurl. Apollo Router, Apollo Client, Apollo Server, Apollo Kotlin, Apollo iOS, and Rover are not affected by this vulnerability as they do not rely on curl or utilize it exclusively with trusted domains. However, some containers in GraphOS Studio that comprise the project may include affected versions of curl, but Apollo does not use SOCKS5 proxies to manage traffic within its environment, which safeguards GraphOS from exposure to the vulnerability. Apollo is conducting an initial review of its projects to identify those that rely on curl and will provide updates as necessary. The company strongly advises customers to apply any available updates to curl as they become available and will promptly communicate any relevant updates or actions needed to address the vulnerability.

Leveraging GraphQL for Next-Generation API Platforms`, a joint paper from Kong and Apollo, explores the need for modern API platforms to securely and efficiently deliver service updates across various interfaces. The authors argue that APIs are increasingly heterogeneous, with legacy SOAP APIs existing alongside new gRPC APIs, making it challenging to iterate, secure access, and scale them. To address this, the paper proposes a vendor-neutral best practice that combines API management and GraphQL into a unified reference architecture for building and operating modern API platforms. This approach leverages GraphQL as a new layer in the stack atop existing microservices and API management, streamlining the developer experience, ensuring secure runtime connectivity, and implementing robust governance mechanisms.

GraphOS is a platform that enables the enforcement of GraphQL security best practices at scale. It provides a unified but modular approach to GraphQL, allowing platform teams to block malicious traffic, define security policies, and provide defense in depth. GraphOS can be used to centralize authorization in the router, safelist registered operations, limit operation complexity, learn security best practices at GraphQL summit, and understand GraphQL security. By using GraphOS, platform teams can improve visibility, security, and scalability for their APIs while balancing flexibility with security measures that prevent bad actors from exploiting its self-serve nature.

GraphQLNullable is not a simple nullability type but rather an enum that provides three cases: some, none, and null. It's used to represent the presence of a value, the implicit absence of a value (nil), and an explicitly null value, respectively. The main difference between nil and null lies in their representation in generated response models; nil is represented as a Swift optional, while null is represented by the GraphQLNullable enum. This distinction becomes important when working with input types, where explicit null values could represent deletion of a field, whereas implicit nil values might imply no change to the field. The GraphQLNullable type was introduced to make it clear that there's a difference between nil and null and forces users to select a case that signals their intent without question.