June 2025 Summaries

Federation in API design is a powerful concept that allows splitting a unified API into multiple subsystems, but the traditional approach using GraphQL Subgraphs has limitations, particularly in terms of type safety, manual data loading, and performance constraints tied to Apollo's specifications. Jens Neuse, CEO of WunderGraph, explores a new approach by replacing GraphQL with gRPC at the Subgraph level to improve performance, simplify architecture, and enhance developer experience, while retaining GraphQL on the client-side. This method removes the dependency on Apollo's gatekeeping, allows faster feature rollouts, and provides more flexibility in language choice for implementing federated services. The Cosmo Router, an open-source project, is central to this approach, handling data loading and batching internally and offering a more predictable and efficient protocol. Despite the shift towards gRPC, GraphQL will continue to be supported for client-facing APIs, ensuring a seamless transition for developers. Neuse emphasizes this evolution as a step towards breaking free from vendor lock-in and fostering innovation in API development.

The text discusses a new approach to implementing GraphQL Federation by replacing Apollo's Subgraph model with a Subgraph to gRPC Compiler, thereby enhancing type safety and performance. This method compiles Subgraph SDLs to gRPC services, eliminating the N+1 problem and offering out-of-the-box support for data loading, thereby facilitating backend engineers to focus on business logic instead of data fetching complexities. gRPC, preferred by backend engineers for its mature technology, allows for strict typing and easier reasoning, while GraphQL remains suitable for frontend operations. The approach includes a gRPC to GraphQL adapter in the Router to translate between the two API styles, maintaining schema-first principles and addressing challenges like expressiveness loss and strict typing. Additionally, a "proto lock file" is introduced to manage field numbers in Protobuf, preventing breaking changes by ensuring field numbers are reserved and tracked over time. This innovative strategy aims to streamline the Federation experience, reduce dependency on GraphQL, and improve the overall API architecture.

The author uses a food park analogy to explain how GraphQL federation can help scale complex systems. The story begins with a single truck serving burgers, which represents a monolithic architecture. As the business grows and more trucks are added, each serving different audiences or products, it becomes increasingly difficult to manage the complexity. This is where Cosmo, a professional waiter, enters the scene. Cosmo knows every truck and can coordinate their operations to provide a seamless experience for customers. The author uses this analogy to explain how federation works, including the need for governance, shared language, and boundaries to ensure that things don't break down when traffic picks up. The goal of federation is to provide flexibility and scalability while maintaining simplicity for customers.

We've accidentally built a backend framework for Large Language Models (LLMs) that simplifies API orchestration. This framework allows developers to build modular monoliths, microservices, or a mix of both, and is inspired by existing frameworks like Vercel's Lovable, Bolt, and Backstage. The framework leverages LLMs to generate code for proxying between the Supergraph and non-GraphQL services, reducing the cost of creating a unified API graph. Cosmo Plugins are the core of this framework, allowing developers to define schemas, compose modules, and generate code using LLMs like Cursor. This approach enables building truly modular monoliths with isolated plugins, making it easier to deploy and manage APIs. The framework is designed to be flexible, allowing developers to choose their own deployment strategy and handle dependencies between plugins in a declarative way.