Cosmo Connect Tutorials for Router Plugins and gRPC Services - WunderGraph

State of GraphQL Federation 2026

How are teams governing schema changes, handling production traffic, and measuring Federation success? Share your experience and get early access to the full report. For every valid survey completed, we'll donate $30 to UNICEF.

TL;DR
Cosmo Connect lets you add federated subgraphs without running a GraphQL server. You define a schema, compile it to a gRPC contract, and implement the RPCs in your own language. This post links three tutorials: a Router Plugin that runs inside the Cosmo Router, a standalone gRPC service you own and scale separately, and an advanced demo that mixes plugins, a GraphQL server, and external services in one graph. Start with a plugin if you want the fewest moving parts, or a gRPC service if you need independent ownership and scaling.

Three Hands-On Tutorials for Federated GraphQL APIs

Cosmo Connect lets you build federated GraphQL APIs without requiring backend teams to run GraphQL servers or frameworks. You define a schema, compile it to gRPC, and let the Cosmo Router handle query planning and batching.

You can get started in three ways:

Can gRPC services be first-class federated subgraphs?

Yes. With Cosmo Connect, a gRPC service is a full member of the federated graph. You describe the subgraph as a GraphQL schema, the wgc CLI generates a strict gRPC contract from it, and the Cosmo Router calls your gRPC implementation directly at query time. The Router handles query planning, batching, and field resolution, so you write RPC methods instead of a GraphQL server.

You keep gRPC as your protocol and any gRPC language you already run, from Go to Java to Python. Existing REST, SOAP, or SDK-backed APIs can be wrapped inside the implementation, so you connect what you have rather than rebuild it.


Deploy Your First Router Plugin

View the full tutorial

This tutorial introduces gRPC Router Plugins—lightweight subgraphs compiled to binaries and managed directly by the Cosmo Router. Instead of deploying a separate GraphQL service, you’ll define a schema, generate gRPC code, and run your business logic as a router-managed process. This keeps latency low, simplifies deployments, and makes it easy to integrate any API.

In this example, you’ll create a plugin called starwars that wraps a minimal portion of the public SWAPI API. It’s a stand-in for your own REST APIs, databases, or third-party services.

The setup includes:

The steps include:

By the end of this tutorial, you’ll be able to query the people field in your federated graph using a router-managed plugin with no separate service deployment.


Deploy Your First gRPC Service

View the full tutorial

This tutorial shows how to build a standalone gRPC service and connect it to your federated graph without running a GraphQL server. Unlike Router Plugins, gRPC services run as independent processes, making them ideal for teams that want clear ownership boundaries, separate scaling, and flexible deployment patterns.

You’ll scaffold a service in either TypeScript or Go using the Cosmo CLI templates. The tutorial walks you through designing a project management schema, generating protobuf files, and implementing queries and mutations.

The setup includes:

The steps include:

By the end of the tutorial, you’ll have a running gRPC service that federates cleanly into the Cosmo Router. This approach gives teams full lifecycle control and is ideal when you need separate scaling and ownership boundaries.


Explore the Advanced Plugin Demo

View the full demo on GitHub

This tutorial demonstrates a federated GraphQL architecture that combines a Cosmo Connect Router Plugin with a standalone Apollo subgraph, showing how plugins can bridge to external services without rewriting backends.

The setup includes:

The steps include:

Key takeaways:

All three tutorials demonstrate how to integrate services into a federated graph without building GraphQL servers. Router Plugins simplify deployment by being managed directly by the Router, gRPC Services provide independence and flexibility, and the Advanced Demo shows how mixed architectures can live side by side. You can start with a plugin or service, then explore the hybrid demo to see how these approaches fit together at scale.


Frequently Asked Questions (FAQ)

Which tutorial should I start with?
Router Plugins are easiest to start with if you want to avoid extra deployments—they run as processes managed by the Router. Choose the gRPC Service tutorial if you need independent scaling and ownership. The Cosmo Plugin Demo shows how to mix both approaches with existing subgraphs.

Do I need to write a GraphQL server for these tutorials?
No. Both tutorials start from a GraphQL schema that compiles to a gRPC contract, without a GraphQL server runtime. The Cosmo Router handles query planning and batching.

Can I combine Cosmo Connect with existing subgraphs?
Yes. The Cosmo Plugin Demo demonstrates a federated graph that mixes Router Plugins, standalone GraphQL servers, and external services.

What languages are supported for gRPC services?
The tutorials include Go and TypeScript templates. You keep any gRPC language you already run, from Go to Java to Python.

Why use Router Plugins instead of services?
Router Plugins run as processes managed by the Router for simpler deployments and lower latency. Services are independent and ideal when you need separate scaling and ownership boundaries.

Can gRPC services be first-class federated subgraphs?
Yes. A gRPC service, or a Router Plugin, is a full subgraph in the federated graph. You define the subgraph schema, generate a gRPC contract with the wgc CLI, and implement the RPCs. The Cosmo Router calls them directly and handles query planning, batching, and field resolution.

Do I need to rewrite my gRPC or proto to use Cosmo?
You do not switch off gRPC or adopt a GraphQL server. Cosmo Connect is schema-first: it generates the protobuf contract from your subgraph schema, and you implement it in the gRPC language and tooling you already use. Existing REST, SOAP, or SDK-backed services can be wrapped inside that implementation instead of rebuilt.