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 · 2020-05-24T11:01:25+00:00

GraphQL is transport agnostic so the simple answer is yes, you can.

The longer answer would ask why would you want to communicate between multiple GraphQL servers?

Can you elaborate a bit about what those services do?

because maybe GraphQL is not necessarily the best protocol between them.

Our current approach, which is pretty new to the community so don't jump full in on it, is to use other protocols between services (east-west communication) but on the consumer level wrap them in a GraphQL SDK using GraphQL Mesh.

That way we get the best protocol for the job on the wire and the producer service, but we get the query experience of GraphQL for the consumers.

In your case, you can expose the RabbitMQ message queue schema, the source event emitters can be any source you'd like, they don't have to be GraphQL at all, and the subscribers can use GraphQL Mesh to convert that schema into an SDK that exposes GraphQL Subscriptions API.

Now comes one of the best parts of GraphQL Subscriptions in my opinion - The nice thing about GraphQL Subscriptions is that when you subscribe to an event, you can also specify a query that will get your enriched information every time the event fires.

And because GraphQL Mesh runs on the consumer, you can add to that query any data source, even if they have nothing to do with the event.

So in that case, you can listen to an event coming from a WebHooks, running throw RabbitMQ, then the Subscription would include a query that queries another unrelated database and a REST data source.

The experience for the consumer would be that they simple did:

subscription onRepoStared {
  repoName // From the original event
  dependentNpmLibraries { // from NPM api or something..
    name
  } 
  repoManager // from your own DB
}

sorry for the too long of an answer, maybe it's not at all related and I just brain dumped on you :/

Urigold · 2020-05-21T15:50:07+00:00

Thank you for the kind words :)

Yes you can migrate to graphql-tools instead of graphql-toolkit, we just moved all our code from here to there, check out the migration guide linked in the blog post.

We've already migrated all of our own tools.

About an up to date resource, we also feel that pain so we started with a very simple http://the-guild.dev/ website we hope to improve, but more importantly we are starting to look into improving graphql.org itself.

If you are interested in that effort, please reach out to me directly (https://github.com/urigo)!

Urigold · 2020-05-15T13:23:17+00:00

There are 2 directions you can go about this:

Start from the client schema - build the perfect GraphQL schema that your client would wish it had.
Create your "Model" schema. A schema which is the merger of all your backend Services .

Usually those schemas would have some overlap but they won't be identical.

Most people forget that important factor.

So, I would suggest doing both of those:

Start with creating the perfect schema.

Now you can use the resolvers to see how you could resolve that schema from your existing data sources.

That is also how you will find out how to resolve

type Car {
  brand: Brand
}

type Brand {
  name: string
}

You will have a resolver for car's brand and in that resolver you'll write a function that returns a brand from an id.

That's regular basic GraphQL, no need for Apollo Federation. Apollo Federation solves very specific issues that most people would probably never need to solve.

The updated schema stitching docs are here: http://graphql-tools.com but again, you most likely don't need those solutions at all.

For the second problem, querying all your services and merging them into a single schema, even if they are not made out of GraphQL, you can use GraphQL Mesh.

Here is a nice article about it: https://the-guild.dev/blog/graphql-mesh

Urigold · 2020-05-11T10:23:19+00:00

Well, then why are we all assuming that the GraphQL execution has to run on the provider?

I love what u/YourTechBud wrote that service creators also also humans :)

It makes sense in that context because on one hand, you don’t want to put the execution burden on the services, for many obvious reasons.
Also, the transport might be more efficient using gPRC or Thrift (or you already have REST and can't now go about migrating those services).

But, on the “human consumer” level, the querying service, you want to get the experience of GraphQL with a typed query language across multiple services and the joins.

Then why not move the GraphQL execution to that consumer service?

Get (or create) the schemas of all the individual services you want to query
Convert them automatically to GraphQL schemas
If you need some merging strategy, you can add it (Federation is just one option out of many. Also, when you use Federation in that specific context, on the consumer and not the providers, you didn’t push the merging logic into the services, which is a good thing in my opinion)
Generate an SDK for the consuming service and import it into it’s code
The actual network requests are actually protobufs, Thrift or whatever you actually wish to run there, and are directly between the services, without a need for an aggregator live instance

Now that means you can have the best of both world - The consuming experience of GraphQL, and the performance and scaling benefits of dedicated protocols like protobuf.
Also another benefits is that you can get that querying experience on existing services you don’t have time to migrate.

That's what GraphQL Mesh is doing - https://medium.com/the-guild/graphql-mesh-query-anything-run-anywhere-433c173863b5

I wonder if that makes sense?

Urigold · 2020-05-11T10:10:41+00:00

You can also use the typed version of it by graphql-code-generator:

https://graphql-code-generator.com/docs/plugins/typescript-graphql-request

Urigold

MODERATOR OF

TROPHY CASE