<img height="393" width="700" src="https://miro.medium.com/v2/resize:fit:630/0*k2U67yFLwscB8eVa" />

Federated GraphQL has been an invaluable tool for enterprise systems because it offers a scalable, decentralized architecture that accommodates evolving data requirements across distributed teams — and their diverse microservices. You have your independent services, merge them into a unified schema with a single endpoint, and now all of your clients can access exactly the data they want, as if it were all coming from a single GraphQL API.

Instead of having a single, monolithic GraphQL server that eventually becomes difficult to scale, you’ve divided your schema and functionality across multiple services.

But the agility, collaboration, and adaptability afforded by such an architecture would hold little value if you didn’t *also* have crucial metrics that let you optimize your data fetching strategies, minimize downtime by patching issues fast, allocate your resources efficiently, and — in general — make informed decisions in the context of your system.

Field-level metrics in federated GraphQL are precisely this detailed insight.

To demonstrate field usage metrics in Federation, I’ll be using [WunderGraph Cosmo](https://wundergraph.com/) — a fully open source, fully self-hostable platform for Federation V1/V2 that is a drop in replacement for Apollo GraphOS.

### Field Usage Metrics 101

What’s a ‘field’ in GraphQL, anyway?

A [field](https://graphql.org/learn/queries/#fields) is just an atomic unit of information that can be queried using GraphQL. Suppose we have these two very simple subgraphs — Users, and Posts:

**Posts subgraph**

```js
type Post @key(fields: "id") {
 id: ID!
 content: String
 authorId: ID!
}
```

**Users Subgraph**

```js
type User @key(fields: "id") {
 id: ID!
 name: String!
}
type Post @key(fields: "id") {
 id: ID!
 authorId: ID! @external
 author: User! @requires(fields: "authorId")
}
```

From these two graphs, we can tell that Users have id’s and names, Posts have id’s, content, and authorId’s — and the shape of each specific data is represented by their respective fields (name is a simple, built-in GraphQL type — a String, while the author of a Post is a compound type represented by the User [object type](https://graphql.org/graphql-js/object-types/)).

The relationship in this example is simple enough — Each Post has a User who authored it, resolved through the authorId field to uniquely identify a User for each Post.

Let’s not go too deep into Federation specific directives here (TL;DR: @key represents the unique identifier for each object type, @external signals that a field is defined in another subgraph and will be resolved externally, via whichever field is presented by the @requires directive — here, authorId).

So if you wanted to query for all Posts along with their User authors, you would request these fields in your GraphQL query:

```js
query allPosts {
 posts {
 id
 content
 author {
 name
 }
 }
}
```

- `posts `is a root query object (technically a field) on the `Posts `subgraph, and contains an array of `Post `type objects.
- `id`, and `content `are fields on the `Post `type.
- `author `is a field on the `User `type. Within the posts query we’re using the relation via `authorId `to reference a `User `from the `Users `subgraph

Field-level usage metrics in GraphQL would track how often these specific fields across different subgraphs are requested in queries on the federated graph. And then, for object types like posts, we could get even more fine-grained and look at the usage of *its* individual fields, in turn.

What does all this information get us?

- **We’d be able to debug issues faster**, because thanks to our metrics we’d know exactly which fields were having trouble resolving data.
- Even if there were no immediate fatal errors, specific performance data for each field would still allow us to **pinpoint bottlenecks or optimization opportunities** — and then we could ship fixes/improvements at different levels: our resolver functions, database queries, or network calls associated with those specific fields.
- Just knowing how many times a specific field has been requested or resolved (taking into account potential caching) within a given timeframe would provide valuable insights into user behavior and needs, help us **streamline the schema and reduce infrastructure costs, or just help us make informed decisions about pricing tiers and resource allocation.**
- We’d have insight into performance trends — error rates, latency, etc. — of specific fields. We could use this to **proactively improve scalability** (ex. a certain field might require ramping up compute power, another might require increased database throughput) based on anticipated increased demand for certain fields, before they ever get bad enough to impact user experience.
- Tracking field-level metrics is crucial for enterprises to **ensure compliance with** [**SLAs**](https://en.wikipedia.org/wiki/Service-level_agreement) —make sure the performance of individual fields meet predefined service-level expectations.

**TL;DR: less reactive firefighting, more proactive optimization.** Let’s show off these metrics for a second.

### Field-usage Metrics with WunderGraph Cosmo

I’ll use WunderGraph Cosmo to federate those two subgraphs. Cosmo is an all-in-one platform for GraphQL Federation that comes with composition checks, routing, analytics, and distributed tracing — all under the Apache 2.0 license, and able to be run entirely on-prem. It’s essentially a drop-in, open-source replacement for Apollo GraphOS, and helpfully offers a one-click migrate option from it.

\[**👉 **[**Cosmo on GitHub**](https://github.com/wundergraph/cosmo)]\(https://github.com/wundergraph/cosmo?source=post\_page-----7e3aeced65be--------------------------------)

The Cosmo platform comprises of:

1. the Studio — a GUI web interface for managing schemas, users, projects, and metrics/traces,
2. the Router — a Go server that implements Federation V1/V2, routing requests and aggregating responses,
3. and the Control Plane — a layer that houses core Cosmo APIs.

The key to managing your Federation with the Cosmo stack is its CLI tool: [wgc](https://github.com/wundergraph/cosmo/tree/main/cli). You install it from the NPM registry, and your subsequent workflow would look something like this:

- Create subgraphs from your independently deployed and managed GraphQL services using `wgc subgraph create`.
- Publish the created subgraphs to the Cosmo platform (or more accurately, to its Control Plane) with `wgc subgraph publish`. This makes the subgraphs available for consumption. Note that the Cosmo “platform” here can be entirely on-prem.
- Once you have all your subgraphs created and published, federate them into a unified graph using `wgc federated-graph create`
- Configure and deploy the Cosmo Router to make your federated graph available to be queried at the routing URL you specified. The Router, in addition to being a stateless gateway that intelligently routes client requests to subgraphs that can resolve them, also generates the field usage metrics for our federated Graph as it’s being queried.

Then, we run a few queries against our federated graph, and then fire up Studio, our web interface.

<img height="402" width="700" src="https://miro.medium.com/v2/resize:fit:630/0*8JCdS8j4sHHkVVkH" />

Studio contains the Schema Explorer, which is the control room for your federated GraphQL ecosystem. Here, you can view and download schemas of all of your subgraphs and federated graphs, and — more importantly in our case — view usage of every single type in your federated ecosystem, from Objects (`Users`, `Posts`) to the Scalars that they’re made of (`Boolean`, `ID`, and `String`), and even the root operation types (each query, mutation, and subscription).

<img height="341" width="700" src="https://miro.medium.com/v2/resize:fit:630/0*QQhnYAZFXF7xwRZn" />

This is an incredibly fine-grained look at your system. Want to know exactly how many times the `author `relation (via `authorId`) was actually accessed when querying for one or more Posts? Go right ahead.

<img height="526" width="700" src="https://miro.medium.com/v2/resize:fit:630/0*MoV_u8OPQ2iu9Mv4" />

The field usage metrics for the author relation here tell you exactly how many clients and operations requested it, along with a histogram for usage. You get to see exactly which operations accessed it, how many times they did so, which subgraphs were involved in resolving requests for this field, and finally, the first and last time the relation was accessed.

### What could these metrics tell us, anyway?

The first thing that jumps out right away from these numbers is that in a real world scenario, certain posts will *always* be more popular than others, but frequent lookups for the same author across multiple posts is redundant, and can and will strain the Users subgraph and its backend. A simple solution could be to implement caching on the User subgraph, and cache author (User) data for the most popular posts, without having to retrieve it every single time.

Since Cosmo lets you filter field usage by client and operation, you might find that your mobile client predominantly accesses the content and author fields, while your analytics dashboard frequently retrieves likes and shares. Now, you can create specialized queries on each client, optimizing for speed and minimizing unnecessary data transfer. Field usage numbers here let you recognize unique requirements of each client type, and their unique field access patterns.

These metrics also show you exactly when a field was accessed over a 7 day retention period (free tier default; extensible), and this is useful in more ways than one: historical usage data, of course, can be used to align caching strategies with predicted future demand, meaning proactive infra scaling (up or down) to avoid bottlenecks during peaks.

But also, the timestamps provide a historical perspective on the adoption and usage patterns of the features each field represents. If you’re not seeing expected usage rate for a certain field/feature, perhaps you need to reassess its relevance to user needs, its value proposition, or even its pricing/monetization strategy.

Simply put, engineers and stakeholders make better decisions on how to evolve the organization’s graphs when they have relevant data to back it up.

### In Summary…

Field level metrics — along with Cosmo’s suite of analytics — ultimately help organizations evolve their federated architecture and deliver a better, more valuable product.

In fact, with deeper insights into how fields are accessed over time, orgs can go beyond just performance optimization to answer questions like: Which fields are consistently accessed together, suggesting potential customization opportunities? Do usage patterns evolve over time? Can we identify underutilized fields for potential streamlining? And these insights inform content strategy, personalization efforts, and even the data model itself.

Of course, the Cosmo platform goes beyond metrics. It includes a blazingly fast V1/V2 compatible Router, visualizes data flow, automates deployments, and integrates seamlessly with your existing infrastructure — you could even migrate over from Apollo GraphOS with one click if you wanted to. And all of its stack is open-source, and completely self-hostable.

<img height="393" width="700" src="https://miro.medium.com/v2/resize:fit:630/0*k2U67yFLwscB8eVa">
Federated GraphQL has been an invaluable tool for enterprise systems because it offers a scalable, decentralized architecture that accommodates evolving data requirements across distributed teams — and their diverse microservices. You have your independent services, merge them into a unified schema with a single endpoint, and now all of your clients can access exactly the data they want, as if it were all coming from a single GraphQL API.
Instead of having a single, monolithic GraphQL server that eventually becomes difficult to scale, you’ve divided your schema and functionality across multiple services.
But the agility, collaboration, and adaptability afforded by such an architecture would hold little value if you didn’t also have crucial metrics that let you optimize your data fetching strategies, minimize downtime by patching issues fast, allocate your resources efficiently, and — in general — make informed decisions in the context of your system.
Field-level metrics in federated GraphQL are precisely this detailed insight.
To demonstrate field usage metrics in Federation, I’ll be using <a href="https://wundergraph.com/">WunderGraph Cosmo</a> — a fully open source, fully self-hostable platform for Federation V1/V2 that is a drop in replacement for Apollo GraphOS.
<h3 id="field-usage-metrics-101">Field Usage Metrics 101</h3>
What’s a ‘field’ in GraphQL, anyway?
A <a href="https://graphql.org/learn/queries/#fields">field</a> is just an atomic unit of information that can be queried using GraphQL. Suppose we have these two very simple subgraphs — Users, and Posts:
Posts subgraph
<pre class="language-js"><code class="language-js code-highlight">type Post @key(fields: "id") {
 id: ID!
 content: String
 authorId: ID!
}
</code></pre>
Users Subgraph
<pre class="language-js"><code class="language-js code-highlight">type User @key(fields: "id") {
 id: ID!
 name: String!
}
type Post @key(fields: "id") {
 id: ID!
 authorId: ID! @external
 author: User! @requires(fields: "authorId")
}
</code></pre>
From these two graphs, we can tell that Users have id’s and names, Posts have id’s, content, and authorId’s — and the shape of each specific data is represented by their respective fields (name is a simple, built-in GraphQL type — a String, while the author of a Post is a compound type represented by the User <a href="https://graphql.org/graphql-js/object-types/">object type</a>).
The relationship in this example is simple enough — Each Post has a User who authored it, resolved through the authorId field to uniquely identify a User for each Post.
Let’s not go too deep into Federation specific directives here (TL;DR: @key represents the unique identifier for each object type, @external signals that a field is defined in another subgraph and will be resolved externally, via whichever field is presented by the @requires directive — here, authorId).
So if you wanted to query for all Posts along with their User authors, you would request these fields in your GraphQL query:
<pre class="language-js"><code class="language-js code-highlight">query allPosts {
 posts {
 id
 content
 author {
 name
 }
 }
}
</code></pre>
<ul>
<li><code>posts </code>is a root query object (technically a field) on the <code>Posts </code>subgraph, and contains an array of <code>Post </code>type objects.</li>
<li><code>id</code>, and <code>content </code>are fields on the <code>Post </code>type.</li>
<li><code>author </code>is a field on the <code>User </code>type. Within the posts query we’re using the relation via <code>authorId </code>to reference a <code>User </code>from the <code>Users </code>subgraph</li>
</ul>
Field-level usage metrics in GraphQL would track how often these specific fields across different subgraphs are requested in queries on the federated graph. And then, for object types like posts, we could get even more fine-grained and look at the usage of its individual fields, in turn.
What does all this information get us?
<ul>
<li>We’d be able to debug issues faster, because thanks to our metrics we’d know exactly which fields were having trouble resolving data.</li>
<li>Even if there were no immediate fatal errors, specific performance data for each field would still allow us to pinpoint bottlenecks or optimization opportunities — and then we could ship fixes/improvements at different levels: our resolver functions, database queries, or network calls associated with those specific fields.</li>
<li>Just knowing how many times a specific field has been requested or resolved (taking into account potential caching) within a given timeframe would provide valuable insights into user behavior and needs, help us streamline the schema and reduce infrastructure costs, or just help us make informed decisions about pricing tiers and resource allocation.</li>
<li>We’d have insight into performance trends — error rates, latency, etc. — of specific fields. We could use this to proactively improve scalability (ex. a certain field might require ramping up compute power, another might require increased database throughput) based on anticipated increased demand for certain fields, before they ever get bad enough to impact user experience.</li>
<li>Tracking field-level metrics is crucial for enterprises to ensure compliance with <a href="https://en.wikipedia.org/wiki/Service-level_agreement">SLAs</a> —make sure the performance of individual fields meet predefined service-level expectations.</li>
</ul>
TL;DR: less reactive firefighting, more proactive optimization. Let’s show off these metrics for a second.
<h3 id="field-usage-metrics-with-wundergraph-cosmo">Field-usage Metrics with WunderGraph Cosmo</h3>
I’ll use WunderGraph Cosmo to federate those two subgraphs. Cosmo is an all-in-one platform for GraphQL Federation that comes with composition checks, routing, analytics, and distributed tracing — all under the Apache 2.0 license, and able to be run entirely on-prem. It’s essentially a drop-in, open-source replacement for Apollo GraphOS, and helpfully offers a one-click migrate option from it.
[👉 <a href="https://github.com/wundergraph/cosmo">Cosmo on GitHub</a>](https://github.com/wundergraph/cosmo?source=post_page-----7e3aeced65be--------------------------------)
The Cosmo platform comprises of:
<ol>
<li>the Studio — a GUI web interface for managing schemas, users, projects, and metrics/traces,</li>
<li>the Router — a Go server that implements Federation V1/V2, routing requests and aggregating responses,</li>
<li>and the Control Plane — a layer that houses core Cosmo APIs.</li>
</ol>
The key to managing your Federation with the Cosmo stack is its CLI tool: <a href="https://github.com/wundergraph/cosmo/tree/main/cli">wgc</a>. You install it from the NPM registry, and your subsequent workflow would look something like this:
<ul>
<li>Create subgraphs from your independently deployed and managed GraphQL services using <code>wgc subgraph create</code>.</li>
<li>Publish the created subgraphs to the Cosmo platform (or more accurately, to its Control Plane) with <code>wgc subgraph publish</code>. This makes the subgraphs available for consumption. Note that the Cosmo “platform” here can be entirely on-prem.</li>
<li>Once you have all your subgraphs created and published, federate them into a unified graph using <code>wgc federated-graph create</code></li>
<li>Configure and deploy the Cosmo Router to make your federated graph available to be queried at the routing URL you specified. The Router, in addition to being a stateless gateway that intelligently routes client requests to subgraphs that can resolve them, also generates the field usage metrics for our federated Graph as it’s being queried.</li>
</ul>
Then, we run a few queries against our federated graph, and then fire up Studio, our web interface.
<img height="402" width="700" src="https://miro.medium.com/v2/resize:fit:630/0*8JCdS8j4sHHkVVkH">
Studio contains the Schema Explorer, which is the control room for your federated GraphQL ecosystem. Here, you can view and download schemas of all of your subgraphs and federated graphs, and — more importantly in our case — view usage of every single type in your federated ecosystem, from Objects (<code>Users</code>, <code>Posts</code>) to the Scalars that they’re made of (<code>Boolean</code>, <code>ID</code>, and <code>String</code>), and even the root operation types (each query, mutation, and subscription).
<img height="341" width="700" src="https://miro.medium.com/v2/resize:fit:630/0*QQhnYAZFXF7xwRZn">
This is an incredibly fine-grained look at your system. Want to know exactly how many times the <code>author </code>relation (via <code>authorId</code>) was actually accessed when querying for one or more Posts? Go right ahead.
<img height="526" width="700" src="https://miro.medium.com/v2/resize:fit:630/0*MoV_u8OPQ2iu9Mv4">
The field usage metrics for the author relation here tell you exactly how many clients and operations requested it, along with a histogram for usage. You get to see exactly which operations accessed it, how many times they did so, which subgraphs were involved in resolving requests for this field, and finally, the first and last time the relation was accessed.
<h3 id="what-could-these-metrics-tell-us-anyway">What could these metrics tell us, anyway?</h3>
The first thing that jumps out right away from these numbers is that in a real world scenario, certain posts will always be more popular than others, but frequent lookups for the same author across multiple posts is redundant, and can and will strain the Users subgraph and its backend. A simple solution could be to implement caching on the User subgraph, and cache author (User) data for the most popular posts, without having to retrieve it every single time.
Since Cosmo lets you filter field usage by client and operation, you might find that your mobile client predominantly accesses the content and author fields, while your analytics dashboard frequently retrieves likes and shares. Now, you can create specialized queries on each client, optimizing for speed and minimizing unnecessary data transfer. Field usage numbers here let you recognize unique requirements of each client type, and their unique field access patterns.
These metrics also show you exactly when a field was accessed over a 7 day retention period (free tier default; extensible), and this is useful in more ways than one: historical usage data, of course, can be used to align caching strategies with predicted future demand, meaning proactive infra scaling (up or down) to avoid bottlenecks during peaks.
But also, the timestamps provide a historical perspective on the adoption and usage patterns of the features each field represents. If you’re not seeing expected usage rate for a certain field/feature, perhaps you need to reassess its relevance to user needs, its value proposition, or even its pricing/monetization strategy.
Simply put, engineers and stakeholders make better decisions on how to evolve the organization’s graphs when they have relevant data to back it up.
<h3 id="in-summary">In Summary…</h3>
Field level metrics — along with Cosmo’s suite of analytics — ultimately help organizations evolve their federated architecture and deliver a better, more valuable product.
In fact, with deeper insights into how fields are accessed over time, orgs can go beyond just performance optimization to answer questions like: Which fields are consistently accessed together, suggesting potential customization opportunities? Do usage patterns evolve over time? Can we identify underutilized fields for potential streamlining? And these insights inform content strategy, personalization efforts, and even the data model itself.
Of course, the Cosmo platform goes beyond metrics. It includes a blazingly fast V1/V2 compatible Router, visualizes data flow, automates deployments, and integrates seamlessly with your existing infrastructure — you could even migrate over from Apollo GraphOS with one click if you wanted to. And all of its stack is open-source, and completely self-hostable.

Making data-driven decisions for evolving your enterprise’s graphs, via field usage metrics.

GraphQL Federation: Field-level Metrics 101

Explore top GraphQL Federation V1/V2 gateways in 2023. Empower your development decisions with insights for seasoned and new GraphQL developers.

Which Federation Gateway Should You Choose In 2023?

Take a shot every time you read about how \[Insert name of technology here\] is Dying™. GraphQL finds itself the latest subject of this narrative. Claims of its downfall, the notion that it has “crashed and burned,” are all over dev spaces.

<img
 height="285"
 width="591"
 src="https://miro.medium.com/v2/resize:fit:591/0*yKSUl1ut7ZQ2ZihM"
/>

Needless to say, this is not a very safe drinking game.

**GraphQL isn’t dying.** It’s just no longer the novel, bleeding-edge technology; no longer the tech Twitter poster child. The hot debates and spicy takes in online forums are dead, but GraphQL itself has matured into a robust, well-understood tool, well-used in production, and well-entrenched in solving real-world problems.

GraphQL has finally become *boring*.

### The Virtues of Being Boring

Boring is stable. Boring is reliable.

GraphQL might have plateaued if you’re looking at StackOverflow Trends…

<img
 height="453"
 width="652"
 src="https://miro.medium.com/v2/resize:fit:652/0*1EStjnlrvDmop0Bq"
/>

…but I’d argue this perceived decline is the calm after the storm of the initial hype cycle, allowing for a more nuanced understanding of its role and purpose within dev ecosystems.

Allow me to explain.

<img
 height="253"
 width="700"
 src="https://miro.medium.com/v2/resize:fit:700/0*h90AWdfcRN4H0OMS"
/>

In 2015, GraphQL was the It technology. In 2023, it’s just another tool in your toolbox.

I think the disconnect here stems from an initial misconception. During GraphQL’s initial hype cycle, it was heralded across developer circles as the REST API killer, poised to obliterate its predecessor. As the dust settled and practical implementations unfolded, with more and more orgs using it in production, we discovered a rather obvious truth — **GraphQL, like any technology, wasn’t a silver bullet.**

We figured out exactly what GraphQL did exceptionally well — It was the undisputed choice if you needed API composition and federating your data dependencies. Its knack for bridging organizational divides between frontend and backend teams, as a shared contract everyone could agree upon, was unmatched. Needed to create mobile apps and account for slower devices and networks? GraphQL was your best bet.

We figured out which use-cases fit GraphQL the best and which did not, we figured out its gotchas and tradeoffs, and we figured out how to deploy it in production. Ergo, it became boring.

**And that’s okay.**

After 8 years, GraphQL being ‘boring’ isn’t a step backward; it’s an indication that the hype behind it has died while GraphQL itself has, dare I say, *won.*

### GraphQL is Now Mainstream

More and more companies now use GraphQL in some form or the other.

<img
 height="382"
 width="700"
 src="https://miro.medium.com/v2/resize:fit:700/0*AbVe2R0MfdPc9NK8"
/>

According to the [2023 Postman State of APIs survey](https://www.postman.com/state-of-api/api-technologies/#api-technologies), GraphQL has only ever grown in YOY Popularity, taking the Top 3 this year.

[Shopify, for example](https://thenewstack.io/why-shopify-favors-graphql-over-rest-for-its-apis/), found the strongly typed structure that GraphQL schemas provide useful in smoothing over client-server data mapping. Previously, any change to an external-facing REST API at Shopify would break client apps, needing clientside devs to statically type a field and cast the over-the-wire JSON response to it every single time, increasing risk. GraphQL schemas being strongly typed provided a foundation that fostered reliability, type safety, and effective contract management within (and without) their ecosystem. **For most orgs (**[**like GitHub**](https://github.blog/2016-09-14-the-github-graphql-api/)**), that and the intuitive querying mechanism for the frontend is all they’ll really need for a GraphQL adoption to pay dividends.**

But what if you have different teams who all use different ‘boring’ technologies, but are siloing knowledge? In this case, it doesn’t matter that you’re only using stable, reliable technology; siloing means you’re still taking on increased organizational risk.

**This is where Federated GraphQL can help.** [Federation](https://www.apollographql.com/docs/federation/) gives you the ability to bring together disparate APIs (gRPC, REST, SOAP, and even GraphQL), microservices, and other data dependencies into a unified interface i.e. a single GraphQL endpoint for every team within the organization — and is probably *the* use-case driving GraphQL adoption in enterprise, where you have unique challenges that most developers will never face: composition without sacrificing scalability (an actual problem, this time), central governance, team autonomy, or adaptability to evolving requirements.

With federated GraphQL architectures, any data added to the organizational data “pool” instantly becomes available to all teams. All companies like [Walmart](https://medium.com/walmartglobaltech/federated-graphql-walmart-bfc85c2553de), [Zillow](https://www.zillow.com/tech/federated-graphql-server-at-scale/), and [Netflix](https://www.infoq.com/articles/federated-GraphQL-platform-Netflix/) had to do was compose any new data source (which could absolutely be *other* federated GraphQL APIs, mind you.) into a central graph, and all of it was immediately available for every team (who could now work autonomously without dependence on other teams’ structures) to query and come up with new and exciting business uses. This federated architecture provides flexibility without having to aggressively refactor or create bespoke new interfaces, and allows for the establishment and enforcement of unified data access policies, validation, auth mechanisms and protocols, and, of course, monitoring oversight that helps in identifying potential bottlenecks, and ensuring adherence to industry-specific regulations like GDPR, HIPAA, or other data protection laws.

GraphQL carves out unique niches rather than serving as an all-encompassing substitute for REST APIs. With the rate at which web development is evolving, a few years down the line you might have a unique problem that just happens to align perfectly with GraphQL’s inherent strengths. Heck, I’ve even seen an example of a frontend team using the GraphQL schema to keep track of the company tech debt via custom directives, meaning their backend teams rarely, if ever, had to go into the frontend codebase to plan refactors. A particularly novel organizational use-case.

Not bad for a technology supposedly on life support.

### Looking To The Future

Listen, if all you take away from this is that GraphQL is not dying, but none of these potential use cases *really* sound compelling right now…**trust your gut.**

You could use a torque wrench to hammer in a nail, if you really wanted to, but it’s probably not going to be worth the infrastructure investment you’ve made, nor the operational headaches you’ll now have to take on.

Similarly, if all you have is a small team with a CRUD app, you shouldn’t shoehorn in GraphQL when a REST API would suffice — and in that case, OpenAPI REST is the “boring” technology you should be adapting right now.

However, if you envision your org or the app growing, anticipating multiple data dependencies or even federated architectures, adopting GraphQL could be a strategic move — and a tool like [WunderGraph](https://wundergraph.com/) could help you get there.

WunderGraph is not one but two products, and which one you choose depends on your most pressing need at the moment.

#### WunderGraph Gateway

If all you need is to manage multiple disparate APIs, all with their own styles, auth protocols, architectures — [WunderGraph Gateway](https://wundergraph.com/gateway) is what you want. This is a free and open-source ([Apache 2.0 license](https://www.apache.org/licenses/LICENSE-2.0)) Backend-for-Frontend framework that can bring together [all of your disparate data sources](https://docs.wundergraph.com/docs/supported-data-sources), whether they’re SQL/NoSQL DB’s (including DBaaS like [PlanetScale](https://planetscale.com/)), ORMs like Prisma, SOAP, OpenAPI REST or GraphQL APIs, Apollo Federation, and even OIDC/non-OIDC compatible auth providers (OpenAuth, Auth0, etc.) — letting you add them all as a simple dependency array, and generating fully-typesafe clients from them for your frontend.

[> GitHub - wundergraph/wundergraph: WunderGraph is a Backend for Frontend Framework to optimize…](https://github.com/wundergraph/wundergraph?source=post_page-----681d3328b31c--------------------------------)

The best part is that while WunderGraph uses GraphQL in your dev environment (introspecting all of your data sources and consolidating them into a single virtual graph that you define GraphQL operations on to get the data you want) no GraphQL is ever shipped to the client, nor is a GraphQL endpoint ever made public. Instead, WunderGraph uses persisted queries. Any arbitrary GraphQL operation you write against the virtual graph is hashed and then saved on the server, only able to be accessed by the client by calling for the hashed name. The WunderGraph BFF server has a list of known hashes — as many Persisted Queries as you define — and will **only** respond to client requests for valid hashes, serving them as JSON over RPC, with a unique endpoint for each and every operation.

**All the devex wins of adopting GraphQL, with none of the drawbacks.** You get blazingly fast stale-while-revalidate caching strategies, and prevent rogue users performing drive-by dumps of your database by reverse-engineering your public GraphQL API.

#### WunderGraph Cosmo

If you know what you’re doing and a Federation V1/V2 architecture is indeed what you want — [WunderGraph Cosmo is for you. This is an open-source (Apache 2.0 License) platform for GraphQL Federation, without vendor lock-in](https://github.com/wundergraph/cosmo). It is a fully self-hostable solution (you retain control of all data), a drop-in replacement for Apollo GraphOS, built on open standards that includes everything you could possibly want to build, manage, and collaborate on federated graphs at scale. It’s an all-in-one solution that contains a schema registry that can check for breaking changes and composition errors, a blazingly fast Federation V1/V2 compatible Router, graph visualization, and an analytics/distributed tracing platform for federated GraphQL.

[> GitHub - wundergraph/cosmo: The open-source alternative to Apollo GraphOS. Building, maintaining…](https://github.com/wundergraph/cosmo?source=post_page-----681d3328b31c--------------------------------)

For enterprise use cases, licensing and data governance (to ensure compliance) are critical — and Cosmo being under an OSI approved license (Apache 2.0) and fully self-hostable makes it the best choice for enterprise adoption of GraphQL. Best of all — if you’re already using Apollo Studio/GraphOS for managing your federated graphs, [you can migrate over with one click.](https://cosmo.wundergraph.com/login)

### In Summary…

The reports of GraphQL’s death have been greatly exaggerated.

GraphQL’s transition to a stable workhorse comes as no surprise — this is just what success looks like. A new technology is overhyped, navigates past it, surviving, becoming a reliable tool in the developer’s arsenal, and solving specific, real-world problems. Acknowledging GraphQL’s perceived plateau in trends is not a declaration of its decline; rather, it’s a testament to its maturity.

In fact, GraphQL is poised to become even more important as diverse API styles become increasingly prevalent. The ability of GraphQL Federation to stitch together various APIs, microservices, and data sources into a coherent and federated structure holds immense promise for organizations. At scale, Federation is the best tool we have for building interconnected systems that can efficiently tap into a shared data pool without compromising the independence of each team or service.

OSI-approved open-source tools like WunderGraph (Cosmo, or the Gateway) not only make it easy for enterprises to adopt GraphQL without licensing hurdles, but make it easier to work with diverse, disparate, evolving technologies without giving up on data governance and distributed autonomy.

Take a shot every time you read about how [Insert name of technology here] is Dying™. GraphQL finds itself the latest subject of this narrative. Claims of its downfall, the notion that it has “crashed and burned,” are all over dev spaces.
<img height="285" width="591" src="https://miro.medium.com/v2/resize:fit:591/0*yKSUl1ut7ZQ2ZihM">
Needless to say, this is not a very safe drinking game.
GraphQL isn’t dying. It’s just no longer the novel, bleeding-edge technology; no longer the tech Twitter poster child. The hot debates and spicy takes in online forums are dead, but GraphQL itself has matured into a robust, well-understood tool, well-used in production, and well-entrenched in solving real-world problems.
GraphQL has finally become boring.
<h3 id="the-virtues-of-being-boring">The Virtues of Being Boring</h3>
Boring is stable. Boring is reliable.
GraphQL might have plateaued if you’re looking at StackOverflow Trends…
<img height="453" width="652" src="https://miro.medium.com/v2/resize:fit:652/0*1EStjnlrvDmop0Bq">
…but I’d argue this perceived decline is the calm after the storm of the initial hype cycle, allowing for a more nuanced understanding of its role and purpose within dev ecosystems.
Allow me to explain.
<img height="253" width="700" src="https://miro.medium.com/v2/resize:fit:700/0*h90AWdfcRN4H0OMS">
In 2015, GraphQL was the It technology. In 2023, it’s just another tool in your toolbox.
I think the disconnect here stems from an initial misconception. During GraphQL’s initial hype cycle, it was heralded across developer circles as the REST API killer, poised to obliterate its predecessor. As the dust settled and practical implementations unfolded, with more and more orgs using it in production, we discovered a rather obvious truth — GraphQL, like any technology, wasn’t a silver bullet.
We figured out exactly what GraphQL did exceptionally well — It was the undisputed choice if you needed API composition and federating your data dependencies. Its knack for bridging organizational divides between frontend and backend teams, as a shared contract everyone could agree upon, was unmatched. Needed to create mobile apps and account for slower devices and networks? GraphQL was your best bet.
We figured out which use-cases fit GraphQL the best and which did not, we figured out its gotchas and tradeoffs, and we figured out how to deploy it in production. Ergo, it became boring.
And that’s okay.
After 8 years, GraphQL being ‘boring’ isn’t a step backward; it’s an indication that the hype behind it has died while GraphQL itself has, dare I say, won.
<h3 id="graphql-is-now-mainstream">GraphQL is Now Mainstream</h3>
More and more companies now use GraphQL in some form or the other.
<img height="382" width="700" src="https://miro.medium.com/v2/resize:fit:700/0*AbVe2R0MfdPc9NK8">
According to the <a href="https://www.postman.com/state-of-api/api-technologies/#api-technologies">2023 Postman State of APIs survey</a>, GraphQL has only ever grown in YOY Popularity, taking the Top 3 this year.
<a href="https://thenewstack.io/why-shopify-favors-graphql-over-rest-for-its-apis/">Shopify, for example</a>, found the strongly typed structure that GraphQL schemas provide useful in smoothing over client-server data mapping. Previously, any change to an external-facing REST API at Shopify would break client apps, needing clientside devs to statically type a field and cast the over-the-wire JSON response to it every single time, increasing risk. GraphQL schemas being strongly typed provided a foundation that fostered reliability, type safety, and effective contract management within (and without) their ecosystem. For most orgs (<a href="https://github.blog/2016-09-14-the-github-graphql-api/">like GitHub</a>), that and the intuitive querying mechanism for the frontend is all they’ll really need for a GraphQL adoption to pay dividends.
But what if you have different teams who all use different ‘boring’ technologies, but are siloing knowledge? In this case, it doesn’t matter that you’re only using stable, reliable technology; siloing means you’re still taking on increased organizational risk.
This is where Federated GraphQL can help. <a href="https://www.apollographql.com/docs/federation/">Federation</a> gives you the ability to bring together disparate APIs (gRPC, REST, SOAP, and even GraphQL), microservices, and other data dependencies into a unified interface i.e. a single GraphQL endpoint for every team within the organization — and is probably the use-case driving GraphQL adoption in enterprise, where you have unique challenges that most developers will never face: composition without sacrificing scalability (an actual problem, this time), central governance, team autonomy, or adaptability to evolving requirements.
With federated GraphQL architectures, any data added to the organizational data “pool” instantly becomes available to all teams. All companies like <a href="https://medium.com/walmartglobaltech/federated-graphql-walmart-bfc85c2553de">Walmart</a>, <a href="https://www.zillow.com/tech/federated-graphql-server-at-scale/">Zillow</a>, and <a href="https://www.infoq.com/articles/federated-GraphQL-platform-Netflix/">Netflix</a> had to do was compose any new data source (which could absolutely be other federated GraphQL APIs, mind you.) into a central graph, and all of it was immediately available for every team (who could now work autonomously without dependence on other teams’ structures) to query and come up with new and exciting business uses. This federated architecture provides flexibility without having to aggressively refactor or create bespoke new interfaces, and allows for the establishment and enforcement of unified data access policies, validation, auth mechanisms and protocols, and, of course, monitoring oversight that helps in identifying potential bottlenecks, and ensuring adherence to industry-specific regulations like GDPR, HIPAA, or other data protection laws.
GraphQL carves out unique niches rather than serving as an all-encompassing substitute for REST APIs. With the rate at which web development is evolving, a few years down the line you might have a unique problem that just happens to align perfectly with GraphQL’s inherent strengths. Heck, I’ve even seen an example of a frontend team using the GraphQL schema to keep track of the company tech debt via custom directives, meaning their backend teams rarely, if ever, had to go into the frontend codebase to plan refactors. A particularly novel organizational use-case.
Not bad for a technology supposedly on life support.
<h3 id="looking-to-the-future">Looking To The Future</h3>
Listen, if all you take away from this is that GraphQL is not dying, but none of these potential use cases really sound compelling right now…trust your gut.
You could use a torque wrench to hammer in a nail, if you really wanted to, but it’s probably not going to be worth the infrastructure investment you’ve made, nor the operational headaches you’ll now have to take on.
Similarly, if all you have is a small team with a CRUD app, you shouldn’t shoehorn in GraphQL when a REST API would suffice — and in that case, OpenAPI REST is the “boring” technology you should be adapting right now.
However, if you envision your org or the app growing, anticipating multiple data dependencies or even federated architectures, adopting GraphQL could be a strategic move — and a tool like <a href="https://wundergraph.com/">WunderGraph</a> could help you get there.
WunderGraph is not one but two products, and which one you choose depends on your most pressing need at the moment.
<h4 id="wundergraph-gateway">WunderGraph Gateway</h4>
If all you need is to manage multiple disparate APIs, all with their own styles, auth protocols, architectures — <a href="https://wundergraph.com/gateway">WunderGraph Gateway</a> is what you want. This is a free and open-source (<a href="https://www.apache.org/licenses/LICENSE-2.0">Apache 2.0 license</a>) Backend-for-Frontend framework that can bring together <a href="https://docs.wundergraph.com/docs/supported-data-sources">all of your disparate data sources</a>, whether they’re SQL/NoSQL DB’s (including DBaaS like <a href="https://planetscale.com/">PlanetScale</a>), ORMs like Prisma, SOAP, OpenAPI REST or GraphQL APIs, Apollo Federation, and even OIDC/non-OIDC compatible auth providers (OpenAuth, Auth0, etc.) — letting you add them all as a simple dependency array, and generating fully-typesafe clients from them for your frontend.
<a href="https://github.com/wundergraph/wundergraph?source=post_page-----681d3328b31c--------------------------------">> GitHub - wundergraph/wundergraph: WunderGraph is a Backend for Frontend Framework to optimize…</a>
The best part is that while WunderGraph uses GraphQL in your dev environment (introspecting all of your data sources and consolidating them into a single virtual graph that you define GraphQL operations on to get the data you want) no GraphQL is ever shipped to the client, nor is a GraphQL endpoint ever made public. Instead, WunderGraph uses persisted queries. Any arbitrary GraphQL operation you write against the virtual graph is hashed and then saved on the server, only able to be accessed by the client by calling for the hashed name. The WunderGraph BFF server has a list of known hashes — as many Persisted Queries as you define — and will only respond to client requests for valid hashes, serving them as JSON over RPC, with a unique endpoint for each and every operation.
All the devex wins of adopting GraphQL, with none of the drawbacks. You get blazingly fast stale-while-revalidate caching strategies, and prevent rogue users performing drive-by dumps of your database by reverse-engineering your public GraphQL API.
<h4 id="wundergraph-cosmo">WunderGraph Cosmo</h4>
If you know what you’re doing and a Federation V1/V2 architecture is indeed what you want — <a href="https://github.com/wundergraph/cosmo">WunderGraph Cosmo is for you. This is an open-source (Apache 2.0 License) platform for GraphQL Federation, without vendor lock-in</a>. It is a fully self-hostable solution (you retain control of all data), a drop-in replacement for Apollo GraphOS, built on open standards that includes everything you could possibly want to build, manage, and collaborate on federated graphs at scale. It’s an all-in-one solution that contains a schema registry that can check for breaking changes and composition errors, a blazingly fast Federation V1/V2 compatible Router, graph visualization, and an analytics/distributed tracing platform for federated GraphQL.
<a href="https://github.com/wundergraph/cosmo?source=post_page-----681d3328b31c--------------------------------">> GitHub - wundergraph/cosmo: The open-source alternative to Apollo GraphOS. Building, maintaining…</a>
For enterprise use cases, licensing and data governance (to ensure compliance) are critical — and Cosmo being under an OSI approved license (Apache 2.0) and fully self-hostable makes it the best choice for enterprise adoption of GraphQL. Best of all — if you’re already using Apollo Studio/GraphOS for managing your federated graphs, <a href="https://cosmo.wundergraph.com/login">you can migrate over with one click.</a>
<h3 id="in-summary">In Summary…</h3>
The reports of GraphQL’s death have been greatly exaggerated.
GraphQL’s transition to a stable workhorse comes as no surprise — this is just what success looks like. A new technology is overhyped, navigates past it, surviving, becoming a reliable tool in the developer’s arsenal, and solving specific, real-world problems. Acknowledging GraphQL’s perceived plateau in trends is not a declaration of its decline; rather, it’s a testament to its maturity.
In fact, GraphQL is poised to become even more important as diverse API styles become increasingly prevalent. The ability of GraphQL Federation to stitch together various APIs, microservices, and data sources into a coherent and federated structure holds immense promise for organizations. At scale, Federation is the best tool we have for building interconnected systems that can efficiently tap into a shared data pool without compromising the independence of each team or service.
OSI-approved open-source tools like WunderGraph (Cosmo, or the Gateway) not only make it easy for enterprises to adopt GraphQL without licensing hurdles, but make it easier to work with diverse, disparate, evolving technologies without giving up on data governance and distributed autonomy.

The reports of GraphQL’s death have been greatly exaggerated. Let’s look beyond trends, instead, at how GraphQL is making organizations better. 

GraphQL is Finally Boring.

Cosmo is a high-performance open-source Federation V1/V2 Gateway, a drop-in replacement for Apollo GraphOS for enterprise federated architectures.

Introduction to WunderGraph Cosmo Router: Open Source Replacement for Apollo GraphOS

Apollo Router's Elastic license preventing adoption? Want to go even faster? This open-source Federation gateway has got you covered.

An Introduction to Cosmo Router: Blazingly Fast Open-Source Federation V1/V2 Gateway

With Cosmo, it's easier than ever to manage your federated GraphQL schemas and prevent composition errors and breaking changes before they reach production.

WunderGraph Cosmo: Open Source Schema Registry with Schema Checks for Federated GraphQL

Federated GraphQL architectures are the way forward for modular microservices-based development. But what happens when you need more than just your standard, garden variety unified GraphQL schema?

An Introduction to Federated GraphQL - and WunderGraph Cosmo

![](https://miro.medium.com/v2/resize:fit:700/1*aKuSeTe7VLW9ZUrWLnYJyg.png)

GraphQL is great in that it truly decouples the frontend from the backend, allowing developers to focus on data needs without being tied down by the specifics of the underlying APIs…or needing to be omniscient about which microservice needs to be hit up for which part of data.

This whole “single, unified API layer to fetch data from all your microservices” approach is perfect for enterprises that not only want the operational benefits of independent teams with a shared contract, but also, to create an enterprise ‘data pool’ that _all_ teams can pull from to create new features and adapt to business pivots and changing client demands.

But such a distributed GraphQL setup is fraught with complexity. Schema stitching has a low barrier to entry, but involves a lot of manual work to bring together your different graphs. Federation, on the other hand, is the more scalable, composable approach that promotes better collaboration across service teams…but is a closed, proprietary solution owned by Apollo (Federation V2 started as MIT, [then transitioned to the Elastic V2 license](https://www.apollographql.com/blog/announcement/moving-apollo-federation-2-to-the-elastic-license-v2/), which the [OSI does not consider open-source](https://opensource.org/licenses/)).

This brings us to what I want to talk about today. How do you build a business around distributed GraphQL if you are perpetually bound to a single-vendor ecosystem?

The time is nigh for [Open Federation](https://open-federation.org/) — a joint effort by [WunderGraph](https://wundergraph.com/) and [The Guild](https://the-guild.dev/) to create a proper specification for federated GraphQL that is truly free and open-source under the MIT license.

### How We Got Here: A Brief History of Federation

With the rise of microservices-based architectures, companies started breaking down large monolithic applications into smaller, independently deployable services, each focused on specific business capabilities, and exposing its own GraphQL schema. To thrive in this environment, GraphQL had to go beyond _just_ flexibility and efficiency; it had to tackle distributed data and schema management challenges.

TL;DR: We needed to merge types and queries from various GraphQL services into a single schema — and so [schema stitching](https://the-guild.dev/graphql/stitching/docs) grew organically as a grassroots solution to this specific problem of composition. With it, developers could create a gateway server that brought together multiple GraphQL schemas — each a service, and each completely independent and unaware of the “stitching”.

![](https://miro.medium.com/v2/resize:fit:700/1*AOxshy3TNhGeHiqZcQMdMw.png)

_Schema stitching_

This had its limitations. If two schemas defined types with the same name, it led to conflicts that developers had to manually fix, either by aliasing types or using custom resolvers. More importantly, stitching lacked a standardized way for services to declare _how_ they could be composed together, and didn’t offer built-in support for dividing a single incoming operation into one or more operations (and ordering their execution) that were each resolvable by a single subgraph. You had to do all this work manually at the gateway level.

Recognizing these shortcomings, Apollo worked on [Apollo Federation](https://www.apollographql.com/docs/federation/), open-sourcing it in 2019. It aimed to provide a more robust and standardized solution to the challenge of building federated GraphQL APIs.

![](https://miro.medium.com/v2/resize:fit:700/1*aQ7eBKLUrT73WV77SERYNg.png)

_Apollo Federation_

Federation introduced a query planning process that allowed the gateway server (a Router) to decompose a query and route its parts to the appropriate services, improving query efficiency and reducing over-fetching. There’s also service awareness — each service could declare its capabilities and relationships with other services using a special SDL (Schema Definition Language) syntax. This made it easier to understand how services fit together in the federated graph.

It also introduced the concept of entity types, representing core business entities — resources, if you will — that could be shared amongst services. This allowed services themselves to declare which types they could reference, or even extend…and if these resources could have shared ownership, it meant better collaboration between teams, as opposed to the strictly decoupled nature of schema stitching.

Federation was a revolutionary new technology, completely different from anything we’ve had until now. It offered a standardized approach to schema composition, query planning, and service awareness. Federation, like nothing before it, let orgs confidently create, scale, and maintain complex, composed APIs that seamlessly integrated data from multiple sources, enabling them to adapt, evolve, and grow.

But then it moved to the Elastic V2 license.

This brings us to the present day, when the GraphQL landscape is at a perfect inflection point. The demand for federated GraphQL architectures is at an all time high — more and more companies want a unified interface into their heterogenous backends (REST, GraphQL, gRPC, Kafka/AsyncAPI, etc.) to create company-wide data pools for organic growth and adaptability — but Apollo Federation is not enough to meet those needs, because of a mix of the technical ambiguity of its specification, and critically, its licensing.

It’s evident that the GraphQL community needs an alternative solution. One that is not owned by any single vendor.

Enter Open Federation, a truly free and open-source approach that not only addresses these limitations, but also champions the principles of openness, accessibility, extensibility, and collaboration. Let’s look at Open Federation and how it’s poised to reshape the future of federated GraphQL.

### Introducing Open Federation

[Open Federation is a FOSS specification for building federated GraphQL APIs that requires no proprietary Apollo Federation libraries](https://spec.open-federation.org/draft).

This is a drop-in replacement for Apollo Federation that enables any vendor, at all, to implement (or extend) it for federated GraphQL solutions of their own, and contribute to a healthier, more diverse GraphQL ecosystem. Walmart, SAP, Tripadvisor, Neo4j, Tailor.tech, and many more companies have pledged their support for it.

The goal of Open Federation is to standardize the process of federation itself — everything from core concepts of subgraphs and federated graphs, to the directives that define them, to algorithms that are needed for query planning and execution, and in general, everything to do with bringing together (and validating) subgraphs into a composed, federated graph — and license all of it under MIT.

**It aims to lay down an in-depth, canonical understanding of federated GraphQL, serving as a source of truth and a collaborative base for anyone who wants to implement federated APIs — or extend the specification however they choose.**

The idea is to foster openness, making it easier for companies to adopt federated GraphQL, work on it, and add their knowledge to the base — all of which ultimately leads to innovations in the GraphQL ecosystem that haven’t been seen until now with Apollo’s single-vendor ecosystem.

### The Three Tenets of Open Federation

#### 1. A True Technical Specification

One of the biggest technical issues with [Apollo’s Federation V2 specification](https://www.apollographql.com/docs/federation/subgraph-spec/) is that it’s too vague. All it says is that your subgraph schemas must make a number of additions to be compatible with the Federation Gateway.

> To be part of a federated graph, an implementing service must conform to the Apollo Federation specification, which exposes the service’s capabilities to the gateway, as well as to tools like Apollo Studio.

```graphql
# ⚠️ This definition must be created dynamically! The union
# must include every object type in the schema that uses
# the @key directive (i.e., all federated entities).
union _Entity
scalar _Any
scalar FieldSet
scalar link__Import
scalar federation__Scope
enum link__Purpose {
  """
  `SECURITY` features provide metadata necessary to securely resolve fields.
  """
  SECURITY
  """
  `EXECUTION` features provide metadata necessary for operation execution.
  """
  EXECUTION
}
type _Service {
  sdl: String!
}
extend type Query {
  _entities(representations: [_Any!]!): [_Entity]!
  _service: _Service!
}
directive @external on FIELD_DEFINITION | OBJECT
directive @requires(fields: FieldSet!) on FIELD_DEFINITION
directive @provides(fields: FieldSet!) on FIELD_DEFINITION
directive @key(
  fields: FieldSet!
  resolvable: Boolean = true
) repeatable on OBJECT | INTERFACE
directive @link(
  url: String!
  as: String
  for: link__Purpose
  import: [link__Import]
) repeatable on SCHEMA
directive @shareable repeatable on OBJECT | FIELD_DEFINITION
directive @inaccessible on FIELD_DEFINITION | OBJECT | INTERFACE | UNION | ARGUMENT_DEFINITION | SCALAR | ENUM | ENUM_VALUE | INPUT_OBJECT | INPUT_FIELD_DEFINITION
directive @tag(
  name: String!
) repeatable on FIELD_DEFINITION | INTERFACE | OBJECT | UNION | ARGUMENT_DEFINITION | SCALAR | ENUM | ENUM_VALUE | INPUT_OBJECT | INPUT_FIELD_DEFINITION
directive @override(from: String!) on FIELD_DEFINITION
directive @composeDirective(name: String!) repeatable on SCHEMA
directive @interfaceObject on OBJECT
directive @authenticated on FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM
directive @requiresScopes(
  scopes: [[federation__Scope!]!]!
) on FIELD_DEFINITION | OBJECT | INTERFACE | SCALAR | ENUM
# This definition is required only for libraries that don't support
# GraphQL's built-in `extend` keyword
directive @extends on OBJECT | INTERFACE
```

That’s all perfectly fine, but…this is only a list of scalars and directives that doesn’t provide a comprehensive specification for Federated GraphQL, like traditional GraphQL does for implementing GraphQL servers and clients. Instead, it’s a rulebook on how to structure your subgraph schemas to be compatible with Apollo tooling, and nothing else.

What if your GraphQL service doesn’t permit types that start with a ‘\_’? What if it doesn’t support unions and/or custom directives? Well, then you’re just out of luck. The official Apollo Federation spec is about facilitating schema composition with a proprietary solution (Apollo), rather than giving you an actual understanding of what individual elements of Federation are, and how they are supposed to work together, so you can build your own solutions or workarounds.

Open Federation seeks to remedy this by defining and documenting a new, standardized approach to federated GraphQL. This means creating a clear, unambiguous, well-documented specification (and critically, opening it up to scrutiny and community review) that defines each directive that defines a subgraph or federated graph, how different GraphQL services can collaborate and federate their schemas, what a “Gateway” should mean in a federated GraphQL context, what it should do, how it’s supposed to route queries and decompose a single client query into subqueries that can each be resolved by a single subgraph, how the Gateway should combine and organize subquery data from various services into a cohesive response and send it back to the client, validation rules for composed graphs, and more.

Making this part of a canonical knowledge base helps developers across various projects and organizations to build federated APIs with a well-defined set of rules and practices, or their own implementation — Gateways/Routers, or their own extended spec altogether — and optimize it for their use case as they go.

### 2. Interoperability With The Existing Ecosystem

For Open Federation to grow, not only do its implementations have to retain cross-compatibility with each other, but they also have to interop with the existing dev ecosystem. Frequently, this means supporting the de-facto way organizations have done federated GraphQL — Apollo Federation — and all existing tooling around it (which includes CI/CD flows, schema registries, composition utilities like `rover`, and Federation-compatible [subgraph libraries](https://www.apollographql.com/docs/federation/building-supergraphs/supported-subgraphs) and [gateways](https://github.com/wundergraph/federation-benchmarks).)

Open Federation recognizes the significance of this ecosystem and aims to enhance it — adding specificity and subtracting ambiguity — but ensuring interoperability with federated GraphQL architectures and dev tools already in place.

**This means that existing Apollo Federation users can adopt Open Federation as a drop-in replacement without significant disruption, or major rewrites**. In fact, _any_ Apollo Federation subgraph can be composed into an Open Federation graph, as the latter builds on top of [existing federation-specific directives](https://www.apollographql.com/docs/federation/federated-types/federated-directives/), further clarifying them.

Adopting Open Federation provides a path for organizations to migrate to a fully open-source solution while preserving their investments in tooling, workflows, and knowledge bases developed around Apollo Federation.

### 3. Extensibility for the Future

The Open Federation spec is a strong base that can be extended by any vendor to create new implementations of federated GraphQL, or new specifications altogether.

For example, if you’re an eCommerce platform, you’d need your federated Gateway to handle high volumes of concurrent requests, even during peak traffic. Rust is a language that has memory safety and low-level control, so your Gateway could use it to implement the Open Federation spec, modified and optimized for your specific use case.

What if your subgraphs needed an auth library that was NodeJS only? No problem, your Gateway could be written in NodeJS and still conform to the Open Federation spec. Now, your implementation is purpose-built for compatibility with the wider JS ecosystem, instead.

A federated GraphQL spec should never hold you back from how you want to work with GraphQL itself.

The perfect example of the kind of open ecosystem Open Federation promotes is [GraphQL Fusion](https://chillicream.com/blog/2023/08/15/graphql-fusion) — a collaborative effort between ChilliCream, The Guild, Hasura, IBM, solo.io, AWS AppSync, and WunderGraph — which was built to solve the problem of organizations relying on a multitude of internal and external data services that are not _only_ GraphQL. It goes above and beyond the capabilities of traditional federated GraphQL to cover diverse, real-world enterprise use cases, enabling them to build unified APIs for _all_ of their data while still shielding the client from implementation details that lie beyond the gateway.

### Shared Knowledge Breeds Innovation

Apollo has done a ton of work in improving the GraphQL ecosystem with [its many open-source GraphQL projects like the Apollo Server and Client libraries](https://github.com/apollographql/), but there’s no denying that the Elastic license, combined with the Federation spec’s inherent ambiguity and a lack of proper documentation holds back widespread adoption of federated GraphQL architectures, and hinders the development of a healthy GraphQL ecosystem for all.

And a healthy GraphQL ecosystem is exactly what Open Federation was built for. An open, shared specification that is not owned and closed down by any single company, one that invites collaboration, serving as a foundation for multiple vendors to build services, solutions, and tooling around, leading to better competition — and more innovation.

Because a thriving GraphQL ecosystem cannot be built upon closed, proprietary solutions from a single vendor.

GraphQL: Open Federation is a Game Changer for Federated Architectures

How do you effectively migrate away from monoliths without getting stuck in Adapter Hell? Let’s talk about the synergy between BFFs and the Strangler pattern, featuring WunderGraph.

Refactoring Monoliths to Microservices with the BFF and Strangler Patterns

![](https://miro.medium.com/v2/resize:fit:700/0*ChDULjgLRWh3h-4d)

Photo by [Arnold Francisca](https://unsplash.com/@clark_fransa?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com/?utm_source=medium&utm_medium=referral)

The Backends-for-Frontends (BFF) pattern is an interesting solution to a problem many teams face — meaningfully decoupling the frontend from the backend, insulating the former from changes to the latter.

In this article, I’m going to quickly explain the BFF pattern, and then focus on some of the best practices you should be following when implementing it. If you’d like to know more about the pattern itself, I’d recommend reading [this interesting article over here](https://samnewman.io/patterns/architectural/bff/).

So let’s get going!

## What is the BFF pattern?

BFF stands for Backend For Frontend, and it’s a very clever way to architect your application in a way so that no matter how many different frontend experiences you offer, the core backend services remain intact.

What does this do differently? Well, sometimes you might be offering very distinct frontend experiences — multiple apps that are meant to re-use your backend services, while each offering very different UXs to your users.

Think of a limited mobile UX, vs. a feature-rich desktop app, vs. a reporting SMS interface. These are three very different UI/UX, all consuming the same business logic at their core. But if you try to create a unique and generic set of microservices that can cater to all of those UI’s needs, you run the risk of introducing unnecessary coupling between the frontend and backend. This always leads to bloated and difficult-to-maintain codebases, and business logic leaking into the frontend.

And we all know, that’s not ideal. _Usually,_ you’ll want your client apps to be “dumb” keeping all the “smarts” on the backend.

And how do we solve this?

![](https://miro.medium.com/v2/resize:fit:700/0*HeOS8I1J9YvsTkeL)

On the right, you’ll see the BFF pattern — creating a second layer of “backend”, one that is specifically built for each UI/UX, that acts as a middleman between the “dumb” UI and the “smart” shared core backend services.

The diagram on the left shows a scenario where you had to make your client apps bigger, bloated, holding some of the business logic required to make it all work.

On the right side though, with a BFF, you can see how the implementation of a new “backend “ layer per UX helps to simplify the client applications, breaking the tight coupling between the frontend and the backend services (whether internal or external APIs), allowing you to update and change them however you see fit, while keeping the client-side code intact (you simply absorb the changes in the BFFs, accordingly).

Now that you have a working understanding of the BFF pattern, let’s take a look at some of the best practices around this interesting pattern.

## 1. Create one BFF per User Experience

The primary role of a BFF should be to handle the needs of its specific frontend client — and no more.

Look at the above diagram, the microservices are still there, they’re the ones that own the “core business logic”. The extra layer added by the BFF is only there to help solve problems that are specific to each UX.

What do I mean by that? In the above example, I proposed 3 different clients for our APIs:

- SMS
- Mobile
- Desktop app

Each of them provides a unique user experience — but what’s critical here is that we’re talking about serving specific needs based on the UI/UX provided, not the specific needs of each separate client implementation.

Even if, for example, there were 2 mobile apps (one for Android and one for iOS), they would still provide (more or less) the same UI/UX, and have similar data needs, therefore you’d only need one “mobile experience” BFF, not one BFF for Android, and one for iOS.

Doing it on a per-client basis would only lead to code duplication for no good reason. There is a significant difference between “the needs of a specific UI/UX” and “the needs of a specific client” that we need to remember when architecting our BFFs.

## 2. Do not reinvent the wheel

Implementing the BFF pattern can be as hard and difficult or as simple and trivial as you want.

My suggestion would be to try and find a framework that gives you the ability to easily implement this pattern without you having to do much.

In the end, what you want is a layer of abstraction over your microservices. One such framework is [WunderGraph](https://wundergraph.com/).

WunderGraph is a “BFF framework” that allows you to bring together all of your underlying services, external APIs, or data sources, and create a single, unified API out of them, thus decoupling your clients from your downstream services.

The following example shows how easy it is to create an app that composes two different external APIs and lets your frontend devs use them without calling them directly.

First. Let’s create a sample NextJS application with WunderGraph included:

npx create-wundergraph-app my-weather --example nextjs

Go into the `my-weather` folder, and run `npm i` . Once it’s done, start the server with `npm start` .

You’ll see a page that displays information about a couple of SpaceX Dragon capsules (WunderGraph uses the SpaceX GraphQL API as an example). Ignore that, and go into the `.wundergraph/wundergraph.config.ts` file, remove the SpaceX API reference, and edit it to look like this, instead:

```typescript
//...
const weather = introspect.graphql({
 apiNamespace: 'weather',
 url: 'https://weather-api.wundergraph.com/',
});
const countries = introspect.graphql({
 apiNamespace: 'countries',
 url: 'https://countries.trevorblades.com/',
});
// configureWunderGraph emits the configuration
configureWunderGraphApplication({
 apis: [weather, countries],
 //...
 },
 //...
});
```

I essentially removed any reference to the SpaceX API and added 2 new API integrations, the `weather` and the `countries` APIs, then added them to the `apis` dependency array.

This file contains the configuration for your WunderGraph BFF Server. Here, you’ll want to add all the APIs you want to compose together — and it doesn’t even have to be data dependencies like microservices, databases, or external APIs. WunderGraph also supports integrating auth via [Clerk](https://docs.wundergraph.com/docs/auth/token-based-auth/clerk), [Auth.js](https://docs.wundergraph.com/docs/auth/token-based-auth/auth-js), or your own auth solution; and even [S3-compatible storage for file uploads](https://docs.wundergraph.com/docs/features/file-uploads-to-s3-compatible-file-storages). All baked into the BFF layer.

Now, you can go to the `.wundegraph/operations` folder and create a file called `CountryWeather.graphql` where we’ll add a nice GraphQL operation that joins information from both APIs.

```graphql
query ($countryCode: String!, $capital: String! @internal) {
 country: countries_countries(filter: { code: { eq: $countryCode } }) {
 code
 name
 capital @export(as: "capital")
 weather: _join @transform(get: "weather_getCityByName.weather") {
 weather_getCityByName(name: $capital) {
 weather {
 temperature {
 max
 }
 summary {
 title
 description
 }
 }
 }
 }
 }
}
```

We’re essentially requesting the capital city of the country we give our operation, and then we’re asking for the weather within that city.

All you have to do now, is go to the `index.tsx` file, and use the `useQuery` hook to request the weather for your favorite country. In my case, I’m going to do:

```typescript
const weather = useQuery({
 operationName: "CountryWeather",
 input: {
 countryCode: "ES",
 },
});
```

And as a result, I’ll be getting this JSON:

```json
{
 "data": {
 "country": [
 {
 "code": "ES",
 "name": "Spain",
 "capital": "Madrid",
 "weather": {
 "temperature": {
 "max": 306.68
 },
 "summary": {
 "title": "Clear",
 "description": "clear sky"
 }
 }
 }
 ]
 },
 "isValidating": true,
 "isLoading": false
}
```

Both APIs were used, their responses collected and stitched together, but from the perspective of a frontend developer, they’d only have to call an endpoint on the BFF server — one that uses a persisted, hashed GraphQL query to get the data needed by the client’s UI/UX, serving the final response as JSON over RPC.

It’s like magic! (You can get the full source code for this project [here](https://github.com/deleteman/wundegraph-bff-example) if you want to review it in detail).

## 3. Watch out for the fan-out antipattern

With the BFF pattern, there is always a chance that you’ll end up with what is known as a “[fan-out](<https://en.wikipedia.org/wiki/Fan-out_(software)>)” problem.

This is when your BFF is responsible for orchestrating API requests to multiple backend services, or third-party APIs — thus introducing multiple points of failure. If any of these called downstream services fail, experience issues, or are otherwise unavailable, it can cause cascading failures in the BFF, ultimately impacting the frontend user experience.

Potential solutions to these problems include:

1. [**Circuit breaker pattern**](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker). With this pattern, you can handle faulty and failing backend services in a controlled manner. When a backend service experiences issues, the Circuit Breaker quickly prevents the BFF from sending additional requests, reducing the time spent waiting for unresponsive services. By isolating the failing backend service this way, the Circuit Breaker prevents cascading failures from affecting other parts of the BFF or frontend application. This ensures graceful degradation during backend unavailability.
2. **Caching**. If a backend service is unavailable, the BFF can provide cached or default data instead of returning an error. Caching frequently accessed data can also help reduce dependencies on backend services and improve response times during periods of backend unavailability — especially when used in conjunction with a Circuit Breaker.
3. **Service monitoring.** If you’re looking to understand how are your services being used (number of requests, most common requests, etc) then the BFF layer is a great place to implement logging, and monitoring the health of backend services and keep track of their availability and performance. The best part is that you can identify and resolve issues proactively with this insight.

## 4. Handle Errors Consistently on the BFF

In my previous example, any of those externals API could’ve failed. If they did, they’d all report errors in wildly different ways. You need to ensure your BFF knows how to handle these errors in a consistent, unified manner, and translate those errors back to the UI in meaningful ways.

In other words, take advantage of the BFF layer and use it as an error aggregator/translator. The client app can’t make sense of an HTTP 500 vs. an HTTP 200 that has an error in the JSON body — and it shouldn’t.

Instead, have the BFF layer standardize error handling. That includes the format of the response, but also its content (i.e. headers, error messages, etc). That way coding the client app to feedback errors to your users in meaningful ways becomes an easier task, since **all your internal error states would now be canonical as far as the client is concerned.**

## 5. Use a Node-based server so you can leverage TypeScript

A NodeJS-based server (Express.js, NestJS, or just WunderGraph’s BFF implementation — which uses a Node/Go server layer) for your BFF lets you use TypeScript on both the frontend and the backend. Embrace its benefits!

TypeScript is a superset of JavaScript that adds static typing, which adds a layer of safety — helping you catch errors early in development, and making your code more maintainable and easier to refactor. If you can use TypeScript to develop both the frontend and the “backend” (the BFF layer), you achieve language consistency throughout the application, making it easier for developers to switch between client and server code without context switching between languages.

As Sam Newman mentions in his blog post, ideally, the frontend team should have ownership of the BFF. Using a Node-based server and TypeScript for both frontend and BFF development, lets them have both in a monorepo, making development, iteration, maintenance, testing, and deployments easier.

In fact, TypeScript can also allow you to share certain code, types, and interfaces between the frontend and the “backend” (actually the BFF). For example, if you have validation logic that is shared between the client app and the BFF, TypeScript can ensure that these shared components are correctly used in both places.

[Here is an article](https://blog.bitsrc.io/sharing-types-between-backend-and-frontend-with-the-bff-pattern-553872842463) I wrote a while ago on how to do just that.

## Conclusion

In the end, BFF is nothing fancy or strange, but rather, yet another layer of abstraction that seats between your UI and the core business logic.

By incorporating these five best practices, you’ll be well on your way to building scalable, maintainable, and performant BFFs, ensuring a great experience for both users and developers alike.

Have you ever used this pattern before? What about WunderGraph as a BFF framework? Share your thoughts in the comments, I’d love to know what you think about them

Best practices to follow when implementing the BFF pattern: do’s and don’ts.

5 Best Practices for Backends-for-Frontends

The Backends-for-frontends (BFF) pattern, [first described by Sam Newman](https://samnewman.io/patterns/architectural/bff/), and first used at SoundCloud, is an effective solution when you have multiple client platforms  -- web browsers, mobile apps, gaming consoles, IoT devices  --  each with unique requirements for data, caching, auth, and more.

The BFF is a custom interface (maintained by the frontend team) that is purpose built for the needs of each client platform, serving as the only “backend” as far as the client is concerned. It sits between the client and underlying data sources/microservices, keeping them decoupled, and giving each client team full control over how they consume, consolidate, and massage data from downstream API dependencies  -- and handle their errors.

But the BFF pattern, like anything else in engineering, has its tradeoffs and drawbacks. As it turns out, though, GraphQL is great at shoring up these flaws, and a GraphQL driven BFF layer works well. However, GraphQL brings with it its own set of problems!

Starting to sound like a broken record, here. How do we break the cycle? Let’s talk about it, with a look at a free and open-source technology  --  [WunderGraph](https://wundergraph.com/)  -- that can help us.

### Backends-for-Frontends ❤ GraphQL

BFFs afford you the luxury of maintaining and securing only a single entry point like you do in simple monoliths, while still working with microservices internally. This gives the best of both worlds, but that kind of agility comes at a price. Let’s take a look at some of these issues, and how GraphQL nullifies them:

**1.** BFFs work great as an aggregation layer, but **you still need multiple requests to get the data you want**, and this scales linearly with the number of Microservices/API/Data dependencies you have. Multiple network hops add latency.

GraphQL works great in minimizing multiple round trips because it natively enables clients to request multiple resources and relationships in a single query.

**2. Overfetching and underfetching might still be problems** because of a combination of how RESTful architectures inherently operate, and the fact that you may be relying on legacy or third-party APIs whose architectures you do not own.

![](https://cdn-images-1.medium.com/max/800/0*WBooDMDU0mvGaJ2G)

Image Source: [https://www.howtographql.com/basics/1-graphql-is-the-better-rest/](https://www.howtographql.com/basics/1-graphql-is-the-better-rest/)

In RESTful APIs, it’s the server that determines the structure and granularity of the data returned, and this can lead to more data than the client actually needs.

GraphQL shifts that responsibility to the client, and they can specify exactly the data they need in a single query.

![](https://cdn-images-1.medium.com/max/800/0*jnw40gftlURwNZSf)

Image Source: [https://www.howtographql.com/basics/1-graphql-is-the-better-rest/](https://www.howtographql.com/basics/1-graphql-is-the-better-rest/)

Whether or not your downstream microservices/APIs are using GraphQL themselves doesn’t matter for the client/BFF interaction. You won’t need to rewrite anything to reap the benefits.

**3. Documentation is going to be an ongoing chore.** A BFF is purpose-built for a specific client, and so each BFF will need detailed accompanying API documentation (with payload/response specifications) to be created and kept up-to-date. If using REST, the endpoint names and HTTP verbs will only grow with the app and its complexity, making them difficult to document, and thus difficult to onboard new hires for.

GraphQL is declarative and self-documenting by nature. There’s a single endpoint, and all available data, relationships, and APIs can be explored and consumed by client teams (via the [GraphiQL interface](https://github.com/graphql/graphiql) or just [Introspection](https://graphql.org/learn/introspection/)) without constantly going back and forth with backend teams.

### …but GraphQL isn’t a silver bullet.

Adopting GraphQL shores up some BFF issues, no doubt, but GraphQL adoption isn’t something to be taken lightly. It’s not just another UI library to add to your tech stack, and much like anything in engineering, it has growing pains, trade-offs, and complexities associated with it.

**1. GraphQL has a steep learning curve.** Understanding its concepts  -- schemas, types, queries, mutations, and subscriptions  --  requires substantial time investment, and writing good resolver functions requires a good understanding of the underlying data models and how to retrieve and manipulate data from different sources (databases, APIs, or services). Server-side data coalescing is a neat idea, but this makes your GraphQL implementation only as good as your resolvers, and involves a ton of boilerplate that can make the implementation more verbose and error prone.

**2. GraphQL has no built-in caching.** The simplicity that GraphQL’s single endpoint format brings to the table can also become a bottleneck in certain circumstances  --  REST APIs’ multiple endpoints allow them to use HTTP caching to avoid reloading resources, but with GraphQL, you’re only using one universal endpoint for everything, and will have to rely on external libraries (like Apollo) for caching.

**3.** **GraphQL clients can be pretty heavy in terms of bundle size that you have to ship**. This might not matter in some use-cases (if you’re only ever building an internal app, for example) but it can and does impact the load time and performance of your application, especially in scenarios where low bandwidth or slow network connections are a concern.

**4. Performance can be a concern, if you’re not careful.** The nature of GraphQL makes it non-trivial to harden your system against drive-by downloads of your entire database. It’s far more difficult to enforce rate limits in GraphQL than it is in REST, and a single query that is too complex, too nested, fetching too much data, could bring your entire backend to a crawl. Even accidentally! To mitigate this, you’ll need an algorithm to calculate a query’s cost before fetching any data at all  -- and that’s additional dev work. (For reference, [this is how GitHub’s GraphQL API does it](https://docs.github.com/en/graphql/overview/resource-limitations))

**5.** **GraphQL doesn’t have a built-in way to ensure security.** REST’s vast popularity and authentication methods make it a better option for security reasons than GraphQL. While REST has built-in HTTP authentication methods, with GraphQL the user must figure out their own security methods in the business layer, whether authentication or authorization. Again, libraries can help, but that’s just adding more complexity to your builds.

### Introducing WunderGraph.

WunderGraph is a free and open-source (Apache 2.0 license) framework for building Backends-for-Frontends.

[**GitHub - wundergraph/wundergraph: WunderGraph is a Backend for Frontend Framework to optimize…**](https://github.com/wundergraph/wundergraph/)

Using WunderGraph, you define a number of heterogeneous data dependencies  -- internal microservices, databases, as well as third-party APIs  --  as config-as-code, and it will introspect each, aggregating and abstracting them into a [namespaced](https://wundergraph.com/docs/overview/features/api_namespacing) virtual graph.

Here’s what a system you might build with WunderGraph would look like.

![](https://cdn-images-1.medium.com/max/800/0*G0nBo2iCw16ao8Bd)

Let’s dive right in. First of all, you’ll have to name your APIs and services as data dependencies, much like you would add project dependencies to a `package.json` file.

#### ./.wundergraph/wundergraph.config.ts

```typescript
// Data dependency #1 - Internal database
const db = introspect.postgresql({
  apiNamespace: "db",
  databaseURL: "postgresql://myusername:mypassword@localhost:5432/postgres",
});

// Data dependency #2 - Third party API
const countries = introspect.graphql({
  apiNamespace: "countries",
  url: "https://countries.trevorblades.com/",
});

// Add both to dependency array
configureWunderGraphApplication({
  apis: [db, countries],
});
```

You can then write GraphQL operations (queries, mutations, subscriptions) for getting the data you want from that consolidated virtual graph.

#### ./.wundergraph/operations/CountryByID.graphql

```graphql
query CountryByID($ID: ID!) {
  country: countries_country(code: $ID) {
    name
    capital
  }
}
```

#### ./.wundergraph/operations/Users.graphql

```graphql
query Users($limit: Int!) {
  users: db_findManyusers(take: $limit) {
    username
    email
  }
}
```

…and WunderGraph will automatically generate endpoints that you can cURL to execute these queries and return the data you want, over [JSON-RPC](https://en.wikipedia.org/wiki/JSON-RPC).

```
> $ curl http://localhost:9991/operations/CountryByID?ID=NZ
> {"data":{"country":{"name":"New Zealand","capital":"Wellington"}}}
```

```
> $ curl http://localhost:9991/operations/Users?limit=5
>{"data":{"users":[{"username":"user1","email":"user1@example.com"},{"username":"user2","email":"user2@example.com"},{"username":"user3","email":"user3@example.com"},{"username":"user4","email":"user4@example.com"},{"username":"user5","email":"user5@example.com"}]}}
```

If you’re using data fetching libraries like [SWR](https://swr.vercel.app/) or [Tanstack Query](https://tanstack.com/query), or a React-based framework (NextJS, Remix, etc.) you get even more out of WunderGraph, as it auto generates a lean, performant, custom TypeScript client for you every time you define an operation, complete with fully type-safe hooks for querying and mutating data that you can use on the frontend, wherever you need it.

#### ./pages/index.tsx

```typescript
// Import data fetching hook from WunderGraph-generated client
import { useQuery } from "../components/generated/nextjs";

const Home: NextPage = () => {
  // Data dependency #1 - Internal Database
  const { data: usersData } = useQuery({
    operationName: "Users",
    input: {
      limit: 5,
    },
  });

  // Data dependency #2 - Third-party API
  const { data: countryData } = useQuery({
    operationName: "CountryByID",
    input: {
      ID: "NZ",
    },
  });

  //...
};
```

Now, you can use `usersData` and `countryData` however you want. Render it out into cards, lists, pass it on to props, go wild.

### But how does WunderGraph address GraphQL’s issues?

Easily - **WunderGraph takes GraphQL completely out of the runtime**.

Yes, you do write GraphQL operations to collect and aggregate the data you want from multiple data sources… but that’s it. You won’t have to write resolvers, or worry about making them efficient at data fetching. Your involvement with GraphQL goes only as far as writing queries, and only during development. No public GraphQL endpoint is ever exposed, nor is any heavy GraphQL client shipped on the client.

Don’t worry if this doesn’t click for you immediately. I promise it’ll make sense soon. Let’s look at this process in detail.

#### GraphQL only during local development?

Whenever you write a GraphQL query, mutation, or subscription and hit save, the Query is NOT saved as is. **Instead, it is hashed and then saved on the server, only able to be accessed by the client by calling for the hashed name** (together with input variables, if needed, of course).

This is what is called a **Persisted Query**. Your WunderGraph BFF server has a list of known hashes  --  as many Persisted Queries as you define  -- and will **only** respond to client requests for valid hashes, serving them as JSON over RPC, with a unique endpoint for each and every operation. (And WunderGraph generates typesafe hooks for React frameworks and data fetching libraries that do the same thing)

What does this mean? Two things.

1.  You address the security concerns associated with having your GraphQL API reverse engineered from browser network requests  --  **because there is no GraphQL API.**
2.  If each operation has a unique endpoint, you can finally implement traditional REST-style caching! But that’s not all. The WunderGraph BFF server generates an [Entity Tag (ETag)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) for each response  --  this is an unique identifier for the content of said response  -- and if the client makes a subsequent request to the same endpoint, and its ETag matches the current ETag on the server, it means the content hasn’t changed. Then the server can just respond with a HTTP 304 “Not Modified”, meaning the client’s cached version is still valid. This makes clientside stale-while-revalidate strategies blazingly fast.

You can write all the arbitrary queries you want using GraphQL during development time, but they’re hashed and persisted at compile time, and only show up at runtime as JSON RPC. In one fell swoop, you have solved the most common issues with GraphQL, creating a best-of-both-worlds scenario. All the wins of GraphQL, with none of the drawbacks.

#### But what about the performance concerns of too-complex queries?

WunderGraph uses the [Prisma ORM](https://www.prisma.io/) internally, crafting optimized queries under the hood for each Operation you write, no matter your data source. You won’t have to worry about hand-rolling your own SQL or GraphQL queries and sanitizing them to make sure a single naïve query doesn’t kill your downstream services, or lead to DOS attacks.

### Where To Go From Here?

You’ve seen how WunderGraph makes building BFFs so much easier, with fantastic devex to boot. Using Prisma under the hood, it creates persisted queries and serves them over JSON-RPC, reining GraphQL back to only being used in local development.

But you can do far, far more than that with WunderGraph --  it’s a true BFF framework:

- It supports fully typesafe development from front to back. Every Operation you write will generate a typesafe client/hook to access it from the frontend…and [you can even generate typesafe Mocks this way](https://docs.wundergraph.com/docs/features/type-safe-mocking)! With WunderGraph, you have shared types between the backend and the frontend  --  giving you full IDE autocomplete and inference both while writing GraphQL queries, and when developing the client.
- It can turn any query you write into a [Live Query](https://docs.wundergraph.com/docs/features/live-queries) without even needing WebSockets  --  making WunderGraph ideal for building BFFs which get deployed together with the frontend to serverless platforms, which _can’t_ use WebSockets.
- It can also integrate [S3-compatible storage for file uploads](https://docs.wundergraph.com/docs/features/file-uploads-to-s3-compatible-file-storages), OIDC/non-OIDC compatible auth providers, and more.
- If you don’t want to write GraphQL at all, you can write custom [TypeScript functions](https://docs.wundergraph.com/docs/typescript-operations-referenc)  --  async resolvers, essentially  -- to define Operations during development. You can perform JSON Schema validation within them using Zod, and aggregate, process, and massage the data any way you want, and then return it to the client. TypeScript Operations are are accessed exactly like GraphQL Operations are (JSON RPC endpoints, or clientside hooks), and run entirely on the server and are never exposed clientside. Plus, you can even import and use existing GraphQL operations within them.
- You can bake cross-cutting concerns that are ideally present on the BFF layer  -- most importantly, auth  --  into WunderGraph’s BFF layer via [Clerk](https://docs.wundergraph.com/docs/auth/token-based-auth/clerk)/[Auth.js](https://docs.wundergraph.com/docs/auth/token-based-auth/auth-js)/your own auth solution, and every Operation can be authentication aware.

With powerful introspection that turns API, database, and microservices into dependencies, much like a package manager like NPM would, WunderGraph makes BFF development accessible and joyful, without ever compromising on end-to-end typesafety. To know more, check out their docs [here](https://docs.wundergraph.com/), and their Discord community [here](https://wundergraph.com/discord).

The BFF pattern optimizes backends for specific client interfaces. Using GraphQL for it fixes some of its drawbacks, but can we do better? Let’s find out with WunderGraph.

Graphql

GraphQL Federation: Field-level Metrics 101

Which Federation Gateway Should You Choose In 2023?

GraphQL is Finally Boring.

An Introduction to Cosmo Router: Blazingly Fast Open-Source Federation V1/V2 Gateway

WunderGraph Cosmo: Open Source Schema Registry with Schema Checks for Federated GraphQL

An Introduction to Federated GraphQL - and WunderGraph Cosmo

GraphQL: Open Federation is a Game Changer for Federated Architectures

Refactoring Monoliths to Microservices with the BFF and Strangler Patterns

5 Best Practices for Backends-for-Frontends

Fixing the Backends-for-frontends pattern with Build-time GraphQL

Last Week in Plain English

Interested in Promoting Your Content?

Help us expand the developer universe!

Main Menu

Follow Us

Graphql

GraphQL Federation: Field-level Metrics 101

Which Federation Gateway Should You Choose In 2023?

GraphQL is Finally Boring.

An Introduction to Cosmo Router: Blazingly Fast Open-Source Federation V1/V2 Gateway

WunderGraph Cosmo: Open Source Schema Registry with Schema Checks for Federated GraphQL

An Introduction to Federated GraphQL - and WunderGraph Cosmo

GraphQL: Open Federation is a Game Changer for Federated Architectures

Refactoring Monoliths to Microservices with the BFF and Strangler Patterns

5 Best Practices for Backends-for-Frontends

Fixing the Backends-for-frontends pattern with Build-time GraphQL

Last Week in Plain English

Interested in Promoting Your Content?

Help us expand the developer universe!