DEV Community: Stefan 🚀

Catching Hidden Compliance Risks in GraphQL Federation with @openfed__requireFetchReasons

Stefan 🚀 — Sun, 15 Mar 2026 19:30:25 +0000

TLDR

@requires isn’t just a helper directive. In practice, it can leak sensitive fields across subgraphs and create compliance headaches. The @openfed__requireFetchReasons directive fixes this by making fetch reasons explicit and giving subgraphs control over who can access sensitive fields.

The Real Problem with @requires

Most of us use @requires without a second thought. It’s convenient, and it works. But in a federated setup, it can quietly bypass the data boundaries you think are in place.

From a compliance angle, that’s dangerous. The audit team might assume a field is locked down, but another subgraph could still access it by tacking on a @requires. That’s how sensitive data ends up in places it shouldn’t.

Example: An Auction Service with a Leak

Here’s a stripped-down case. A fictional company, LeeWay, lets people auction off their old software. Two subgraphs handle the logic:

Auction subgraph defines the auction and its sensitive minimumPrice.
Description subgraph extends the type with a description field that uses @requires.

# Auction Subgraph

type Query {
  auction(id: ID!): Auction!
}

type Auction @key(fields: "id") {
  id: ID!
  title: String!
  minimumPrice: Int!
}

# Description Subgraph with exploitable directives.

type Auction @key(fields: "id") {
  id: ID!
  minimumPrice: Int! @external
  description: String! @requires(fields: "minimumPrice")
}

Now if a client asks for description, the Router will fetch minimumPrice from the Auction subgraph and pass it along:

{
  "query": "query($representations: [_Any!]!) { _entities(representations: $representations) { ... on Auction { description } } }",
  "variables": {
    "representations": [
      { "__typename": "Auction", "id": "1", "minimumPrice": 100 }
    ]
  }
}

Suddenly, minimumPrice is exposed. Authorization checks still exist, but compliance controls are broken because another subgraph now has access.

Fixing It with @openfed__requireFetchReasons

WunderGraph’s @openfed__requireFetchReasons directive locks this down. You apply it to the sensitive field:

# Auction Subgraph

type Query {
  auction(id: ID!): Auction!
}

type Auction @key(fields: "id") {
  id: ID!
  title: String!
  minimumPrice: Int! @openfed__requireFetchReasons
}

With the directive, the Router includes fetch reasons in the extensions field:

{
  "extensions": {
    "fetch_reasons": [
      {
        "typename": "Auction",
        "field": "minimumPrice",
        "by_subgraphs": ["Description"],
        "is_requires": true
      }
    ]
  }
}

The Auction subgraph can then parse this and decide: is the Description subgraph allowed to fetch this field? If not, deny it.

To cover direct user access, the Router adds a by_user flag:

{
  "extensions": {
    "fetch_reasons": [
      {
        "typename": "Auction",
        "field": "minimumPrice",
        "by_user": true
      }
    ]
  }
}

That way, you can distinguish between a legitimate client request and a dependency from another subgraph.

Compliance and Audit Benefits

This isn’t just about passing audits. The directive makes sensitive data access explicit, declarative, and auditable. Without safeguards, @requires can expose sensitive fields to other subgraphs.

With @openfed__requireFetchReasons, you don’t have to guess. The schema itself carries the compliance rules, and the runtime enforces them.

Wrap-Up

If you’re working with GraphQL Federation and care about data boundaries, don’t ignore @requires. It can punch holes in your compliance story. The @openfed__requireFetchReasons directive gives you a clean, declarative way to control fetch reasons and build trust into your schema.

Originally posted on WunderGraph’s blog

Entities and Batching Cosmo Connect vs Apollo Federation vs GraphQL Federation

Stefan 🚀 — Sun, 15 Mar 2026 16:13:24 +0000

Federation gives teams a way to build one API layer from many services. The three main options—Apollo Federation, GraphQL Federation (Composite Schemas), and Cosmo Connect—share this goal but solve the problem differently.

Apollo Federation

Uses GraphQL subgraphs with @key to define entities.
The Router batches lookups through the _entities field.
Strong composition checks ensure subgraphs join cleanly.
Drawback: every subgraph must be a GraphQL server. Connectors exist for REST, but they can leak backend details into the API contract.

GraphQL Federation (Composite Schemas)

Driven by the GraphQL Foundation’s Composite Schemas spec.
Keeps GraphQL “vanilla” by using @lookup directives instead of _entities.
Pros: federation without Apollo-specific extensions.
Cons: entity status is less explicit, and batching is not built in. Routers must alias or send multiple requests.

Cosmo Connect

Keeps explicit @key directives, but replaces GraphQL subgraphs with gRPC services.
You define SDL, generate a proto, and implement RPCs.
Two integration models:
Router Plugins (managed processes inside the Router).
gRPC Services (independent services with full scaling and ownership).
The Router handles batching, retries, auth, and rate limits.
gRPC contracts are strict and batch-friendly by default.

Batching Compared

Apollo Federation: _entities gives built-in batching.
GraphQL Federation: @lookup requires manual batching strategies.
Cosmo Connect: gRPC RPCs accept lists of keys, batching is automatic.

Conclusion

All three approaches aim to build a unified API layer with entities. Apollo Federation relies on _entities, GraphQL Federation uses @lookup, and Cosmo Connect compiles SDL into strict gRPC contracts. The tradeoffs lie in how entities are defined and how batching is handled.

Developers often ask the same practical questions when starting with Connect. Here are the most common ones:

FAQs

What’s the difference between Apollo Federation and GraphQL Federation? Apollo Federation adds _entities, _Any, and @key. GraphQL Federation avoids these and uses @lookup.

When should I use Cosmo Connect instead of GraphQL subgraphs? If you want federation without GraphQL servers. Connect compiles SDL to gRPC contracts, and the Router manages platform concerns.

Does Cosmo Connect work with REST APIs and SDKs? Yes. Implement RPCs that call REST or SDKs. The Router provides retries, rate limiting, and auth.

How does batching differ across the three? Apollo Federation batches with _entities. GraphQL Federation needs router-side batching. Cosmo Connect includes batch-capable gRPC methods out of the box.

This post is a condensed summary. The full blog with code examples and history is published on the WunderGraph blog.

Why Schema Changes Take Months in GraphQL Federation (And What the Fix Looks Like)

Stefan 🚀 — Wed, 11 Mar 2026 20:18:01 +0000

This is a summary of a longer piece published on the WunderGraph blog. Read the full article here.

If you've worked on a large federated graph, you've probably lived this: a frontend team needs a new field. The resolver takes an afternoon to write. Getting approval to write it takes three weeks.

The reason isn't technical. Federation's composition model is sound — subgraphs give teams independent ownership, the composition layer produces a unified graph, and consumers get one place to query. The problem is everything that has to happen before implementation can start.

The coordination problem, specifically

Say you need a shippingEligibility field on User, combining data from a fulfillment service and a compliance service. Before anyone writes a resolver, someone has to answer:

Which subgraph owns User? Which team owns that subgraph?
Can that team extend User with a type they don't own the data for?
What does the fulfillment team need to expose, and in what shape?
Does the compliance team's data have a natural entity key that maps cleanly to User?
Who approves the field name, the type structure, the nullability decisions?

None of these are hard questions in isolation. But in an organization running 50 or 100 subgraphs, with ownership distributed across many teams, the process of answering them — Slack threads, design docs, platform team review, scheduling across backlogs — is where time goes.

The implementation was never the bottleneck. Alignment was.

Why Federation doesn't solve this

Federation was designed to solve a different problem: how do you scale a GraphQL schema technically across many teams? The answer — distributed subgraph ownership with a composition layer — is a good one for that problem.

But Federation composes bottom-up. Each team builds their subgraph independently. The supergraph is whatever the composition process produces. There's no design artifact that represents what the consumer-facing API should look like before teams start building. The supergraph emerges; it isn't specified.

This means there's no natural place for a frontend team to say "here is what we need" and have that statement drive the work. Instead, they have to reverse-engineer who owns what and negotiate the shape of the API across team boundaries — every time.

What a top-down model looks like

WunderGraph's post argues that the workflow should run in reverse. Start with the consumer's ideal query — what they would ask for if there were no constraints. Design the supergraph to answer it. Then figure out which subgraphs need to change and what each team is responsible for.

In their Fission model, a schema change begins as a supergraph-level proposal. A new type or field is sketched in terms of the consumer contract, before any subgraph assignment happens. The full article walks through the shipping eligibility example step-by-step, including how entity keys get propagated across subgraphs. Tooling then identifies which subgraphs are affected, propagates entity key requirements automatically, and routes the proposal to the right owners for review. Each team approves their slice. Implementation begins with a validated, agreed-upon spec.

The result is that the coordination which currently happens informally — across Slack, Miro boards, and meetings — gets a structured surface. Affected teams are identified automatically rather than through institutional knowledge. Sign-off is tracked rather than assumed.

What this means for teams running large supergraphs

The value of this model scales with graph size. At five subgraphs with one team, informal coordination is fine. At fifty subgraphs with fifteen teams, the absence of a structured design-time workflow is itself a product risk. Changes move slowly not because engineers are slow, but because the process of getting alignment has no tooling support.

Fission is positioned as a design-time complement to Federation's runtime machinery — not a replacement. Query planning and execution stay with Federation. The workflow for deciding what the supergraph should look like, and getting teams aligned on it before implementation begins, is what Fission addresses.

It's also, the post notes, the model that makes most sense as AI agents start contributing to API development. An agent that can query the supergraph for existing capabilities and propose structured changes for missing ones — with a human reviewing before anything ships — fits naturally into this workflow. The coordination layer has to exist for that to work at all.

The full article walks through an example of a schema change. Read it on the WunderGraph blog.

Running Federation with Cosmo: No Glue Code, No Surprises

Stefan 🚀 — Mon, 09 Mar 2026 18:57:45 +0000

If you caught Part 1, we walked through Federation with a food park analogy. This time, we're digging into what Cosmo actually does.

It’s not magic. Cosmo validates, routes, and coordinates your GraphQL subgraphs using the schema itself, so you get fewer bugs, fewer surprises, and no glue code to maintain.

🧠 Schema Composition: Catching Issues Before They Go Live

Every morning (or CI run), each team submits their subgraph schema to Cosmo. Cosmo composes them into a supergraph and checks for:

Duplicate type or field names
Ownership conflicts
Missing types or fields required by another subgraph

If anything’s off, composition fails and sends the schema back for review.

You’ll see exactly which service caused the issue and why—before it breaks your API.

📦 Query Planning: Routing Based on Ownership

Once everything’s composed, Cosmo uses the supergraph to plan how to resolve queries. Each field is mapped to the subgraph that owns it.

Let’s say a client sends:

graphql

query OrderSummary {
  sides { name }
  drinks { type }
}

Cosmo builds a query plan that looks like:

1. Send `sides` query to Fry Truck subgraph  
2. Send `drinks` query to Smoothie Truck subgraph  
3. Stitch together response and return to client

All of it is driven by schema metadata—no hand-coded routing rules, no guesswork.

⚠️ When Things Break: Cosmo Handles Fallback

Stuff goes wrong. Services go down. Fields error out. Cosmo doesn’t crash the whole response.

Here’s what it does instead:

Follows fallback rules if they’re defined
Retries if configured
Returns partial data and suppresses internal errors when needed

Fallback behavior is defined in the routing layer, not guessed at runtime.

📡 Real-Time Subscriptions: Subgraphs + Pub/Sub + Cosmo

Here’s the catch with subscriptions: they’re hard to federate.

Cosmo solves this with EDFS—Event-Driven Federated Subscriptions. Each subgraph sends events to a pub/sub system like NATS or Kafka. Cosmo listens to those streams, maps the events to the right GraphQL subscription using the composed schema and routing metadata, and filters out anything the client didn’t ask for.

No polling. No global fan-out. No manual wiring. Cosmo handles everything through the same schema-aware routing layer you’re already using for queries.

🧰 You Focus on Features. Cosmo Runs the Federation.

You don’t have to build orchestration logic from scratch. Cosmo takes care of:

Schema composition
Query planning
Runtime routing
Error masking and fallback
Federated subscriptions

It connects with your GitHub repo, deploys via the CLI, and lets you track everything in Studio.

Cosmo doesn’t just move data. It’s how your federated platform stays reliable at scale.

Next up: Schema contracts and how Cosmo enforces them before things break.

Read the original: wundergraph.com/blog/behind-the-counter-how-cosmo-works

Event Lifecycle Control in GraphQL Subscriptions

Stefan 🚀 — Sun, 08 Mar 2026 13:38:46 +0000

Cosmo Streams adds three handlers to the router that control subscription behavior: authorization when a client subscribes, per-subscriber filtering while events flow, and validation when mutations publish events. Instead of building custom subscription infrastructure, you write Go functions that run at specific points in the event lifecycle.

What EDFS Already Solved

EDFS connects your message broker to GraphQL subscriptions. The router listens for events and publishes them as subscriptions. This remains the foundation of how Cosmo Streams operates.

Cosmo Streams extends that by moving subscription authorization, event filtering, and mutation validation into the router itself. Three handlers cover three stages: when a subscription starts, while events are in flight, and when mutations publish events.

Authorization Was All or Nothing

EDFS gave you binary access: authenticated users could subscribe to any topic. There was no way to scope access based on roles, user attributes, or subscription context.

Teams worked around this by building custom services, adding resolver checks, or processing events after delivery. That meant managing connection state, duplicating auth logic, and manually fanning out events.

SubscriptionOnStart Handler

The SubscriptionOnStart handler runs when a client subscribes. You have access to JWT data, HTTP headers, connection details, and GraphQL variables. Use this context to allow or deny the subscription.

Example: users subscribe to order updates. The handler validates the JWT and issuer before allowing the subscription. Once established, the OnReceiveEvent handler filters which events each subscriber receives based on permissions.

Two users subscribe to the same GraphQL subscription but see different events. Per-subscriber filtering wasn't possible with EDFS alone.

New Subscribers Started from Zero

EDFS is purely event-driven. Subscribe, then receive future events as they happen. Efficient, but creates UX issues.

A user joins a live soccer match stream. Score is already 1-0. With EDFS, they see nothing until the next goal, which might be 30 minutes away. The client is connected but has no context.

Initial State via SubscriptionOnStart

The same handler that handles authorization can send data immediately when a subscription starts.

A client subscribes to an in-progress match. The router queries the current score, sends it immediately, and then continues streaming future goals. The client gets the initial state, then the event stream.

One handler, two problems: access control and initial data delivery.

Everyone Got Identical Events

EDFS fanned out events to all subscribers identically. Simple, performant, but inflexible. Some teams needed to filter or modify events per subscriber.

Two users subscribe to the same topic. One's an admin who should see everything. The other's a regular user who should only see their own data.

OnReceiveEvent Handler

OnReceiveEvent runs when an event arrives from the broker, before the router delivers it. Executes once per subscriber, enabling per-subscriber decisions about delivery.

Example: user subscribes to order updates, receives only events from orders they created. Handler filters based on customer ID from the token matched against customer ID in the event.

This filtering happens for each subscriber. 30,000 subscribers means 30,000 handler executions. Router handles these asynchronously with configurable concurrency limits.

Mutation Side Validation

OnPublishEvent runs when a mutation publishes an event through Cosmo Streams, before the router emits to the message system. Validates or enriches data before it enters your event infrastructure.

Example: user creates an order via mutation. Handler validates the user is creating an order for themselves, not another user. Matches customer ID from token against customer ID in mutation input.

Without this, router-level validation was difficult. EDFS just transformed mutation data into events and sent them out. Now you have a validation layer before events enter your system.

Implementation

Handlers are implemented through the Custom Module system. Write logic in Go as modules that compile with the router.

Three extension points:

SubscriptionOnStart - when subscriptions start
OnReceiveEvent - when events arrive from broker
OnPublishEvent - when mutations publish events

All handlers are optional. Without them, router falls back to standard EDFS behavior.

Performance

OnReceiveEvent processes every subscriber individually. 30,000 subscribers = 30,000 handler runs per event batch.

Don't make API calls per handler run. That's 30K external calls per event with 30K subscribers. Use in-process or external caches. Custom Modules are Go functions, so you can run async routines and look up pre-computed data instead of hitting upstream systems.

Handler logic must be efficient. The router handles concurrency and memory management, but blocking operations at this scale will cause problems.

Getting Started

The demo repository shows all three handlers with a working order system. See how SubscriptionOnStart validates JWTs, how OnPublishEvent ensures users only create their own orders, and how OnReceiveEvent filters events so customers see only their own orders.

Cosmo Streams turns GraphQL subscriptions from a broadcast pipe into a policy-aware event system with control at subscribe time, in-flight, and at publish time.

Adapted from the original article on the WunderGraph blog.

Extending Your GraphQL Router with TypeScript

Stefan 🚀 — Sun, 08 Mar 2026 05:19:25 +0000

Cosmo Connect now supports TypeScript plugins. If you're already working in a TypeScript codebase, you can extend your GraphQL router without introducing Go or deploying additional services.

Why This Matters

Until now, router plugins required Go. That works fine for teams already using it, but creates friction for everyone else. Since most teams already write TypeScript, adding native support removes that barrier.

The typical use case: you need to expose some internal logic or wrap a legacy REST API without spinning up another service. Write a TypeScript plugin, define your GraphQL type, call your API, and transform the response. It functions like a subgraph but lives inside the router.

The Technical Setup

Cosmo Connect generates protobuf definitions from your GraphQL schema. When you write a plugin, you define the schema, generate the protos, implement handlers, and publish. The router handles the rest.

Scaffold a new plugin:

bash

wgc router plugin init planets --language ts

Generate protobuf definitions:

bash

wgc router plugin generate --plugin-dir ./planets

Your schema might look like:

graphql

type Query {
  planet: Planet!
}

type Planet {
  name: String!
  mass: Float!
}

Every schema change requires regenerating protos so your plugin code has access to new fields.

Implementation

Handler logic goes in src/plugin-server.ts. Here's a simple example:

typescript

public async QueryPlanet(
  call: ServerUnaryCall<QueryPlanetRequest, QueryPlanetResponse>,
  callback: sendUnaryData<QueryPlanetResponse>
): Promise<void> {
  const response = new QueryPlanetResponse();
  const planet = new Planet();
  planet.setName("Earth");
  planet.setMass(5.972e24);
  response.setPlanet(planet);
  callback(null, response);
}

In production, replace this with calls to your internal services, databases, or legacy systems.

Build and publish:

bash

wgc router plugin build --plugin-dir ./planets
wgc router plugin publish planets --namespace <namespace>
wgc subgraph update planets --namespace <namespace>

The router reloads automatically, and your new field appears in the schema.

Schema Validation

Published plugins go through standard composition rules. No special checks for TypeScript. Test in the Playground like any other field.

Go vs TypeScript

Go plugins shipped first because the router is written in Go and uses HashiCorp's go-plugin library - most mechanics are handled out of the box. TypeScript required building more integration ourselves, which took longer.

If you want deeper context on our plugin architecture decisions, Jens wrote about it in REST in Peace—Connectors Were Never the Right Supergraph Abstraction.

Getting Started

Best way to learn: wrap a single REST endpoint. Define the type, implement the handler, publish, and query. You'll understand the full workflow in a real environment.

Complete walkthrough in our plugin tutorial.

Adapted from the original article on the WunderGraph blog.

AI Accelerates Implementation. It Can't Fix Your Federation Coordination Problem.

Stefan 🚀 — Thu, 05 Mar 2026 20:03:47 +0000

This is a summary of a longer piece on the WunderGraph blog. Read the full article here.

There's a common assumption in platform engineering right now: AI will speed everything up. LLMs write code faster. Implementation cycles shrink. Teams ship more.

That's true for the parts of the job that are already well-defined.

The bottleneck in GraphQL Federation development isn't implementation. It's alignment. And alignment is exactly what LLMs can't help with.

Where the Time Actually Goes

If you're running Federation at scale, you are probably familiar with this pattern. A frontend engineer needs a new field. The implementation is straightforward — maybe a few hours of work. But before a line of code gets written, someone has to answer a set of organizational questions:

Which subgraph owns the type where this field belongs?
Is that team in a position to add it right now?
Does the proposed field name conflict with conventions in other subgraphs?
Who needs to approve this before it's safe to compose?

None of these are technical problems. They're coordination problems. And in organizations running dozens or hundreds of subgraphs, they're expensive ones. Complex schema changes can take months, not because the code is hard, but because getting the right people aligned is.

The current toolset for this coordination: Slack threads, Miro boards, meetings, and platform engineers acting as human routers for every schema change request. It works until it doesn't.

LLMs Make This Worse Before They Make It Better

Here's the dynamic to pay attention to: as LLMs reduce implementation time, alignment becomes a larger fraction of total cycle time. If implementation drops from a week to a day, but coordination still takes three weeks, you haven't meaningfully accelerated anything.

The velocity problem in Federation isn't that engineers write code too slowly. It's that getting to "here's exactly what to build" — the right field name, the right type, the right subgraph, with sign-off from the right teams — is where time disappears.

LLMs accelerate the last mile. They don't touch the first three.

The Structural Issue Underneath

There's an architectural reason coordination is hard in Federation, and it's worth naming.

Federation composes the supergraph bottom-up: subgraph teams build independently, and the supergraph is whatever the composition layer produces. The consumer-facing API is a side effect of what teams happened to build.

GraphQL's original design principle was the opposite: the schema is a contract shaped around what consumers need. Federation, as commonly practiced, inverts this.

WunderGraph's response to this is an approach called Fission — designing the consumer-facing supergraph first, then decomposing that design into work for subgraph teams. Proposals start at the supergraph level. Affected subgraphs and their owners are identified automatically. Each team reviews and approves their portion before implementation begins.

This makes the coordination explicit and trackable rather than ad hoc.

What Agents Actually Need

The coordination problem gets more acute when you extend it to AI agents.

An agent working on behalf of a user needs to know what capabilities exist in the graph. If a capability is missing, it needs a way to request it. As Cloudflare has noted, it doesn't work to expose thousands of API endpoints to an agent; you need a structured, searchable graph.

Hub is designed with this trajectory in mind. The vision: an agent queries Hub via MCP to discover what capabilities exist, proposes a schema change if something is missing, and implements it once a human approves. AI handles what it's good at while humans retain judgment over API design decisions. Hub is the coordination layer between them.

The Practical Takeaway

If you're planning to use AI to accelerate your API development workflow, the investment that will actually move the needle isn't better code generation. It's better coordination infrastructure.

Federation solved the technical problem of decomposing a graph across teams. It left the organizational problem largely unsolved. That's the gap governance tooling fills.

LLMs will keep getting better at writing subgraph resolvers. The teams that compound that velocity are the ones that also solve alignment.

The full article goes deeper into Fission and the architecture of Hub. Read it on the WunderGraph blog.

How We Built WunderGraph’s Engineering Growth Framework

Stefan 🚀 — Tue, 03 Mar 2026 21:05:22 +0000

At WunderGraph, we’ve nearly tripled our team in under a year. With that growth came the need for a clear career framework to keep hiring fair, growth conversations meaningful, and pay benchmarks consistent for a global team.

Our Engineering Growth Framework is built around impact—not just what you ship, but how you work and who benefits. It focuses on three areas:

1. Engineering Excellence

– technical skills, ownership, and problem-solving

2. Partnering with Others

– collaboration and knowledge sharing

3. WunderGraph Culture

– living our values and ways of working

It supports two equal tracks—Individual Contributor and Management—with clear steps for progression in both. We already use it in hiring, onboarding, 1:1s, and performance reviews.
The framework is version 1 and will evolve with feedback. Senior roles like Staff and Principal Engineer are calibrated for both technical leadership and strategic alignment.

We’re hiring engineers who want to grow in an environment built on clarity and impact.

Full post and public framework here:

👉 The WunderGraph Engineering Growth Framework

The Manifesto That Keeps Our Remote Team Moving Fast

Stefan 🚀 — Wed, 18 Feb 2026 22:18:13 +0000

At WunderGraph, we build Cosmo, a GraphQL API management platform for federated graphs at scale. Our team is fully remote—30 people in 9 countries—and we just raised our Series A.

As we’ve grown, we’ve learned that how we work is just as important as what we ship. So we wrote our Manifesto: 17 beliefs that define how we hire, collaborate, and deliver.

Why it exists

We want everyone pulling in the same direction, with clarity on what’s expected and what success looks like here.

What it covers

Ownership. Urgency. Customer obsession. Direct feedback. A willingness to wear any hat. These aren’t slogans—they’re daily habits.

How we use it

Shared with every candidate before the first interview
Part of onboarding for new hires
Published in our public handbook

What’s next

We’ll review and expand it at our next company retreat in Gran Canaria, evolving it into a values framework that can scale with us.
If you want to work in a place where speed, trust, and impact matter, check out our open roles.

Full post here:
👉 How Our Core Beliefs Drive the Way We Scale

Compliance Debt in AI Systems

Stefan 🚀 — Wed, 11 Feb 2026 07:28:08 +0000

Every AI deployment now carries audit risk.

For high-risk AI in Europe, logging and documentation are legally mandated. In the United States, states are building their own rules with no consistency. In parts of Asia, certain high-impact AI systems face mandatory risk assessments and pre-deployment scrutiny.

Non-compliance blocks sales, delays integrations, and forces engineers to rebuild systems under pressure.
The only sustainable path is making compliance part of the design. Build systems that record evidence as they run.

Three Layers of Evidence

Despite regional differences, every regulatory framework asks for the same proofs:

What was shipped: models, configurations, schemas, and artifacts.

Who changed it: access logs, RBAC/SSO identities, approvals, version history.

How changes were governed: linting results, governance checks, signed configs, CI-based controls.

These layers clarify what auditors mean when they ask for "documentation" or "technical files."

EU AI Act

The EU AI Act entered into force on August 1, 2024. Key obligations for high-risk AI systems phase in over roughly two to three years, with most provider duties applying from 2026-2027.

Once obligations begin, high-risk AI providers must:

Generate and retain logs for at least six months, longer where necessary based on the system's purpose or other EU/national laws.
Keep technical documentation and compliance records available for 10 years after the system is placed on the market or put into service.

Fines can reach up to €35 million or seven percent of global turnover.

US State Approaches

No comprehensive federal law exists. States have taken over.
In the 2025 session, lawmakers in all 50 U.S. states considered at least one AI-related bill or resolution.

Colorado regulates "high-risk" systems with focus on algorithmic discrimination and transparency, requiring impact assessments, consumer disclosures, and notification to the Attorney General within 90 days when discrimination risks are discovered.

California targets frontier models rather than use cases. SB 53 requires large frontier-model developers to publish safety/transparency disclosures and report certain critical safety incidents within 15 days, or within 24 hours when there is imminent risk of death or serious injury.

New York maps high-risk directly to employment. The proposed Workforce Stabilization Act would require AI impact assessments before workplace deployment and impose tax surcharges when AI displaces workers.

Texas pursued both youth safety and AI governance. The Texas Responsible Artificial Intelligence Governance Act, effective January 1, 2026, establishes statewide consumer protections, defines prohibited AI uses, and creates enforcement mechanisms.

Utah requires disclosure when consumers interact with generative AI and mandates stricter upfront disclosure for licensed professions and designated 'high-risk' AI interactions.

Each state treats 'high-risk' differently—employment decisions, youth safety, frontier models, discrimination, transparency. Engineering teams design for multiple compliance targets with no federal standard to unify them.

Asia Pre-Deployment Review

China mandates lawful training data, consent for personal information, and clear labeling for synthetic content.

India initially proposed stricter draft guidance pointing toward mandatory government approval for some AI systems in early 2024, then revised its advisory and removed the explicit government-permission language while continuing to emphasize transparency, consent, and content safeguards.

South Korea's AI Basic Act, effective in 2026, will add mandatory risk assessments and local representation for high-impact systems.

Compliance Costs

Building Audit-Ready Infrastructure

Identity-Linked Event Trails

Audit-ready logs provide immutable, identity-linked events that allow teams to replay a decision path. If you cannot reconstruct what happened, you cannot satisfy traceability requirements.

Policy Enforcement in CI/CD

Policy enforcement in CI prevents misconfigured models or insecure schemas from entering production. Every blocked change becomes an approval record.

Access Governance

Access governance connects each action to a verified identity through SSO, SCIM, and RBAC. This creates a chain of accountability that enforcement agencies can verify.

Versioning

Versioning links prompts, models, and configurations to their exact commit or revision. This establishes a reproducible audit history for every component.

Compliance Maturity Model

Audit Readiness Checklist

Step One: Map Evidence Gaps

Compare existing logs, approvals, and version history against regional requirements. Identify where traceability breaks or where evidence is missing.

Step Two: Stabilize the Basics

Ensure six-month log retention, CI policy checks, and identity-based approvals. These controls form the minimum reliable audit trail.

Step Three: Automate and Operationalize

Add inference-level tracing, compliance coverage KPIs, and region-specific audit bundles. This turns compliance from reactive work into automated evidence generation.

When proof is generated automatically, regulation stops blocking delivery. Teams that build evidence into their systems answer audit requests in hours. Teams that don't spend weeks reconstructing logs, defending gaps, and explaining why critical evidence doesn't exist.

Adapted from the original article on the WunderGraph blog.

Why We Replaced GraphQL Subgraphs with gRPC Services in WunderGraph Cosmo

Stefan 🚀 — Mon, 08 Dec 2025 21:42:11 +0000

When teams adopt GraphQL Federation, they usually split their API into Subgraphs. Each Subgraph speaks GraphQL, and the Router stitches them together at runtime.

But after years of working with Federation, we kept hitting the same limits…Type safety, performance, and the bottlenecks of Subgraph frameworks.

So we asked:

What if Subgraphs didn’t need to use GraphQL at all?

We built a new model in WunderGraph Cosmo. The Router still speaks GraphQL at the edge, but Subgraphs now run as gRPC services behind the scenes.

Here’s how it works and why we made the switch.

GraphQL Subgraphs Look Clean, But Aren’t Type Safe

A Subgraph might start simple:

type User @key(fields: "id") {
  id: ID!
  name: String!
}

But when the Router queries that Subgraph, it sends this:

{
  "representations": [
    { "__typename": "User", "id": "1" },
    { "__typename": "User", "id": "2" }
  ]
}

The _entities field uses a list of _Any. There’s no compile-time check that your resolver handles the shape correctly. You might not catch issues until runtime or production.

By switching to gRPC, we eliminate this risk. Type mismatches fail at codegen, not later.

Subgraphs Still Leave You With N+1 Problems

GraphQL has a known issue with N+1 queries. Subgraph frameworks don’t solve this for you; you’re expected to implement a data loader yourself.

That works fine for small services, but it doesn't scale. Every team ends up solving the same problem, again and again.

In Cosmo, the Router already handles batching and query planning. If your Subgraphs are gRPC services, they receive batched requests out of the box without needing custom logic.

GraphQL Adds Overhead That gRPC Skips

Every Subgraph written in GraphQL has to parse, validate, normalize, and execute the incoming request. That’s a lot of work for a small data fetch.

Even with an optimized Router, performance can tank if a Subgraph is implemented in a slower language or framework.

With gRPC, we bypass all that. The Router just sends a single request. There is no parsing or dynamic execution. That saves CPU, latency, and developer effort.

Apollo’s Gatekeeping Slows Everyone Down

One of the biggest issues in the Federation ecosystem is Apollo's control over the Subgraph spec and its frameworks. You can’t ship new features until they do. Even when they do, it takes time for other frameworks to catch up.

With gRPC, we’re free to move faster. New Router features are immediately usable by any service that supports gRPC—no framework rewrites required.

From GraphQL SDL to gRPC in Practice

You still write a GraphQL Subgraph SDL:

type User @key(fields: "id") {
  id: ID!
  name: String!
}

But instead of implementing that in a Subgraph framework, we compile it to this:

syntax = "proto3";
package service;

service UsersService {
  rpc LookupUserById(LookupUserByIdRequest) returns (LookupUserByIdResponse) {}
}

message LookupUserByIdRequestKey {
  string id = 1;
}

message LookupUserByIdRequest {
  repeated LookupUserByIdRequestKey keys = 1;
}

message LookupUserByIdResponse {
  repeated User result = 1;
}

message User {
  reserved 2 to 3;
  string id = 1;
  string name = 4;
}

The repeated field handles batching. The reserved tags prevent field conflicts when evolving the schema. It’s fast, reliable, and strictly typed.

You can register the service like this:

subgraphs:
  - name: users
    routing_url: localhost:4011
    grpc:
      schema_file: ./schema.graphql
      proto_file: ./generated/service.proto
      mapping_file: ./generated/mapping.json

No runtime SDL parsing. No entity resolution bugs. Just fast, typed calls between the Router and backend services.

You Still Write GraphQL. You Just Don’t Implement It.

This doesn’t mean ditching GraphQL entirely. The Router still exposes a GraphQL API to your clients.

But everything behind the Router can run on gRPC. That makes it faster and more predictable. And it frees your team from framework lock-in.

If you're curious about how we map GraphQL to gRPC, read the deep dive:

➡️ The Next Generation of GraphQL Federation Speaks gRPC

To try it out, start here:

➡️ Cosmo gRPC Quickstart

For the original post, visit WunderGraph’s blog.

What’s Next?

We’re not removing GraphQL. But we are making Subgraphs faster, safer, and easier to evolve. And we believe this model will become the new standard.

You can follow our work or join our Discord to chat with the team.

How We Replaced GraphQL Subgraphs with gRPC for Safer, Faster Federation

Stefan 🚀 — Mon, 08 Dec 2025 20:57:11 +0000

If you've worked with Apollo Federation, you’ve probably used Subgraphs to scale a GraphQL API. But the way entities are resolved between Subgraphs introduces real problems at scale, especially around type safety and correctness.
At WunderGraph, we took a different approach. Instead of resolving entities through GraphQL between services, you can now compile Subgraph SDLs directly into gRPC services. This provides strict typing, built-in batching, and a significantly faster execution model, without compromising the benefits of GraphQL at the router level.
You can read the original deep-dive on our company blog.

Why Entity resolution in Apollo Federation breaks down

In Apollo Federation, each Subgraph defines entities using the @key directive. The router stitches them together using a special _entities field.

The problem? That _entities field accepts a list of _Any. That means there’s no compile-time validation. You can’t tell whether one Subgraph’s resolver will match the expected shape from another.

This often leads to subtle runtime bugs, and we've seen this firsthand with teams using Federation at scale.

What if your router spoke gRPC instead?

Many teams already use gRPC internally and expose GraphQL through shim layers. Backend engineers prefer gRPC’s type safety and performance. Frontend engineers prefer GraphQL’s flexibility.

So we built a system that connects both worlds:

A compiler that turns GraphQL SDLs into gRPC service definitions
A router adapter that translates GraphQL queries into gRPC calls

That means no more GraphQL-to-GraphQL entity lookups between Subgraphs. You can still write GraphQL at the router boundary, but downstream it’s speaking gRPC.

From SDL to gRPC: How it works

Here’s a simple GraphQL Subgraph:

type Query {
  me: User!
}

type User @key(fields: "id") {
  id: ID!
  name: String!
}

Our compiler transforms it into this proto file:

syntax = "proto3";
package service;

service UsersService {
  rpc LookupUserById(LookupUserByIdRequest) returns (LookupUserByIdResponse) {}
  rpc QueryMe(QueryMeRequest) returns (QueryMeResponse) {}
}

message LookupUserByIdRequestKey {
  string id = 1;
}

message LookupUserByIdRequest {
  repeated LookupUserByIdRequestKey keys = 1;
}

message LookupUserByIdResponse {
  repeated User result = 1;
}

message QueryMeRequest {}

message QueryMeResponse {
  User me = 1;
}

message User {
  string id = 1;
  string name = 2;
}

This solves two problems at once:

Requests are batched by default, avoiding N+1 issues.
Everything is strictly typed, so there’s no ambiguity between Subgraphs.

Instead of relying on _Any, you now have a method that guarantees structure and order. Backend engineers no longer need custom data loader logic. The router batches calls automatically.

View full proto examples here

Mapping GraphQL types to gRPC

Here’s how the translation works:

Object types → protobuf messages
Scalars:
- String → string
- ID → string
- Int → int32
- Float → float
- Boolean → bool
Enums → protobuf enums
Input objects → protobuf request messages
Queries and Mutations → gRPC service methods

Example

type Query {
  getBook(id: ID!): Book
}

type Book {
  id: ID!
  title: String!
  pages: Int
}

Becomes:

message GetBookRequest {
  string id = 1;
}

message GetBookResponse {
  Book book = 1;
}

message Book {
  string id = 1;
  string title = 2;
  int32 pages = 3;
}

service QueryService {
  rpc GetBook(GetBookRequest) returns (GetBookResponse);
}

Schema evolution with proto lock files

Protobuf enforces field numbers. Once you use a number, you can’t reuse it for another field with a different type.

To manage this, we introduced a proto lock file that reserves previous field numbers:

message User {
  reserved 2;
  string id = 1;
  int32 age = 3;
}

This prevents breaking changes if you remove a field and later add a new one.

Want to try it?

We’ve published a full quickstart tutorial and reference docs.

This is just the first step. We’re building a new Federation model where GraphQL stays at the edge, and the internals run on fast, type-safe gRPC.

Let us know what you think:
Join our Discord