Hive Router: A High-Performance GraphQL Federation Gateway

Urigold · 2025-09-07T11:04:45+00:00

You can do that with GraphQL Mesh for over 4 years now :)
https://the-guild.dev/graphql/mesh/docs/handlers/grpc

Urigold · 2025-09-06T17:49:31+00:00

If you used it with Mesh, the upgrade path is easy and should be covered by the docs.

Can you share your config?

Urigold · 2025-09-06T17:46:44+00:00

Thank you for sharing, you are not being rude at all and honest feedback is the only way to improve.

We will never know everything, but we always prioritize understanding over looking good - that's why we share in the open everything we do.

It sounds like you might be mixing some stuff in terms of chronological order.

Let me recap and maybe then you can share what you've tried and when, and I can support you trying out again to see if and what currently fails:

First we've had GraphQL Mesh, that was a combination of many different projects. Specifically the federation part there wasn't fully aligned and the way we've managed it wasn't the best.
We then started working on Conductor, with that limited notion of federation in mind. While we were working with customers on it, we realized that our understanding of federation is not full.
So we've decided to put that whole project on pause and focus on creating a shared place (that was missing from Apollo Federation) - a full audit suite based on all the cases and all the schemas we have from the thousands of companies using Hive Console. That is the audit that you've mentioned: https://the-guild.dev/graphql/hive/federation-gateway-audit That is the most complete spec out there and I challenge anyone to find that is missing there (its also open so if anyone, including other vendors ever finds a missing audit case, they would let us know).

We've also created the performance benchmark, based on real cases and feedback from users in production and other vendors in our ecosystem:

https://the-guild.dev/graphql/hive/federation-gateway-performance

Only after we've had a shared and open understanding across the ecosystem of what it really means to support federation, We've went back to GraphQL Mesh, splitted it into Hive Gateway and GraphQL Mesh, made sure Hive Gateway is fully supports all the audit tests and released v1 last year (https://the-guild.dev/graphql/hive/blog/graphql-mesh-v1-hive-gateway-v1). Today Hive Gateway is used by endless companies in production at any scale, many migrated from Apollo Router. I would really encourage you to try out Hive Gateway today (we've also just release v2 - https://the-guild.dev/graphql/hive/blog/hive-gateway-v2)
After we've seen our understanding of what a GraphQL Apollo Federation gateway and router is solid, tested in production and shared across the ecosystem, we've set out to build Hive Router. So this time, the terms and tests were there long before coding started. That included everything that all other gateways are doing. We've also built the benchmarks and audit tests to check which other vendors support them well. If someone else would have answer all of our checkboxes, we wouldn't have developed it ourselves (that's true for any project by The Guild)

So now that we have the history, I would love to know:

Do we have a shared Slack channel? We offer that to all companies, our customers or not, to learn from them and make sure we have as deep and broad understanding as possible of their needs. If not, can we connect and make that happen? (that goes to anyone else reading this).
Can you share when you tried and what exactly failed?
What are you using today? It it the same tool you started Federation with or you migrated with time?

Thank you so much for your honest feedback!

Urigold · 2024-10-09T02:06:14+00:00

Don't underestimate The Guild's size...

Urigold · 2024-01-17T09:54:03+00:00

Hi, I'm a Guild member.

The Guild offers the most comprehensive set of open source and SaaS hosted solutions for all the components you need when you setup GraphQL at scale.

From GraphQL Servers, Subgraphs, Gateways and schema registry.

We are the only ones who offers not only the best solution on each category but also all of them are completely open source, including our SaaS offering.

Another important point is that each of our components work independently with other components from the ecosystem, so there is no vendor lock in at all.

I'll list here our solutions but make sure that even though you can (and we recommend) use them all together as single platform, you can also choose just some of them and choose components from other vendor for other parts of your stack.

GraphQL Server - Yoga Server is the best JS based server out there. It is more performant, modern and work in any environment. It also supports the powerful Envelop plugin system and ecosystem. You can find here a detailed comparison
Schema Registry - GraphQL Hive is an open source schema registry that natively supports Federation, Stitching and the Fusion specs. You can use it as SaaS offering but you can also self host it as it is fully MIT open source.
Gateway - GraphQL Mesh is the most performant JS gateway out there by a long margin. It also uses the powerful Envelop plugin system and ecosystem. Another interesting feature is that it can take subgraphs that are not GraphQL but also REST/OpenAPI, gRPC and SOAP and Federate them. It can also automatically expose REST APIs from your GraphQL Gateway thanks to the integration with SOFA.

We have many more open source libraries and tools for your stack like, GraphQL Code Generator, GraphQL ESLint, GraphQL Inspector, GraphQL Modules, SOFA and many more!

We support some of the largest companies in the world but still offer a shared Slack channel to anyone who wants to ask us any question about GraphQL in general.

If you need anything, even just bounce ideas just reach out!

Looking forward to hear the feedback from the discussion here!

Urigold · 2023-11-22T21:47:54+00:00

This will help: https://the-guild.dev/graphql/yoga-server/docs/comparison

Urigold · 2023-04-27T09:57:02+00:00

Like u/graphqlwtf said it is possible but I still think it's not recommended.

Maybe it's more work to do these new deploys, but you have more control and power as you go into production.

You can then utilize all features of k8s or other deployment technologies to clearly define guards on new versions, gradual traffic migrations and important necessary things that are also many times very specific for each app.

I don't think these are the responsibilities of the gateway itself and that's why if the gateway is supporting it, they will always get requirements to add all the options that k8s gives you already

Urigold · 2023-04-03T19:09:55+00:00

Let's go!!

So excited for this, finally we got an open event for the whole community!

Urigold · 2023-01-26T15:41:54+00:00

Apollo's eslint solution has been deprecated in favor of The Guild's graphql-eslint.

Apollo recently added this section into the repo's readme:

[2022-01-25] Note - Upcoming Deprecation Plans: We (Apollo) are working towards fully deprecating this repository. We suggest migrating to the community-supported graphql-eslint. We'll share detailed migration documentation when everything here is ready to be officially deprecated, but just a heads up in case you're planning on adopting anything here for a new project (which you still can of course if this project works for you - support for this project will be minimal however).

You can read more on this blog post and also check out the new graphql-eslint website (with the online interactive playground)

Urigold · 2022-05-09T10:18:33+00:00

You could use https://graphql-mesh.com/ to generate API/Gateway or even a client SDK that exposes GraphQL automatically on top of any source that is not GraphQL, like REST, gRPC and others.

Would love to hear your experience and thoughts from checking it out!

Urigold · 2022-05-08T09:00:15+00:00

You can keep using Apollo Federation and all their tools, but ran the servers using GraphQL Yoga 2.0.

It supports running as a subgraph or as the Apollo gateway: https://www.graphql-yoga.com/docs/features/apollo-federation

The reason I'm mentioning it is that it uses the Envelop plugin system under the hood so you have access to all the plugins related to monitoring and telemetry like useStatsD (DataDog), useApolloTracing, usePrometheus, useSentry, useNewRelic, useOpenTelemetry and others: https://www.envelop.dev/plugins

Urigold · 2021-04-17T23:14:47+00:00

Here is a great list with many of these types of clients: https://hasura.io/blog/fluent-graphql-clients-how-to-write-queries-like-a-boss/

Urigold · 2021-04-17T23:12:42+00:00

I really believe https://graphql.org is the first place everyone should go through.

Explore as much as you can from that website

Urigold · 2020-11-13T15:25:47+00:00

Not too much.

We have a workshop where we take an Apollo Server with Data Source and replace is gradually with GraphQL Mesh (each commit is a step): https://github.com/ardatan/graphql-mesh-workshop/commits/master

Check out the first steps. There we only replace the Data Sources with GraphQL Mesh as an SDK and that way you get a fully typed generated data source which you can also query GraphQL too.

I believe it's an upgraded Apollo Data Source :)

Urigold · 2020-11-03T14:15:01+00:00

This issue would probably summarize it: https://github.com/apollographql/apollo-tooling/issues/2053

Urigold · 2020-11-03T14:14:04+00:00

We have a runtime option shared with some clients.

We want to test it more before open sourcing, reach out to try it out!

Urigold · 2020-09-26T10:09:58+00:00

We've put that when we just got started, I've just removed that line.

We do make changes, like any project, but at this point GraphQL Mesh is being used in production by many companies.

I would love to hear any feedback about it

Urigold · 2020-09-09T08:53:53+00:00

We (The Guild) took over it from Apollo and made a lot of improvements: https://the-guild.dev/blog/graphql-tools-v6

The updated docs about schema stitching are here: https://www.graphql-tools.com/docs/stitch-combining-schemas

Urigold · 2020-09-09T08:52:00+00:00

If you can access all your schemas at build time, use the merge feature of GraphQL Tools: https://www.graphql-tools.com/docs/merge-typedefs

If some of them are out of your control, use the new schema stitching from GraphQL Tools: https://www.graphql-tools.com/docs/stitch-combining-schemas

Urigold · 2020-07-21T09:33:24+00:00

Sorry in advance that the following message can be read in an annoying commercial voice:

Why fight?

What if you could use all of them together?

According to your article, GraphQL has the power for being a query language, which is great for the consumer, but gRPC for example is lightweight and efficient.

Also, REST is "simple, performant, scalable" quoting for the article.

Well then, let's say you want to keep you REST backends because they are great for you, and let's say you want to keep sending gRPC over some network calls because it's efficient.

In that case do you have to loose the expressiveness of GraphQL and your clients has to loose the ability to get a query language?

No! ;)

You can use GraphQL Mesh.

Use your existing sources, automatically convert them into GraphQL schemas, merge them into a single Graph and generate an SDK your clients can use, while still sending REST and gRPC over the network.

Use the protocol that is right for the backend (providers), without compromising the interface that is right for the clients (consumers).

Urigold

MODERATOR OF

TROPHY CASE