// the find
ardatan/graphql-mesh
🕸️ GraphQL Federation Framework for any API services such as REST, OpenAPI, Swagger, SOAP, gRPC and more...
GraphQL Mesh is a gateway/federation framework from The Guild that wraps non-GraphQL sources (REST, OpenAPI, gRPC, SOAP, OData, MySQL, MongoDB, Neo4j) into a single GraphQL schema, or composes multiple subgraphs into a Federation supergraph. It's for teams with a pile of legacy or protocol-mismatched services who want one GraphQL entry point without rewriting those services.
Source handler coverage is genuinely broad, not just REST-to-GraphQL window dressing — gRPC, SOAP/WSDL, OData, Thrift, and direct DB handlers are all first-class, each backed by its own e2e test directory. Schema transforms (type merging, hoisting, prefixing, naming conventions) let you reshape an ugly upstream schema without touching the source service. It's backed by The Guild, the same org behind graphql-yoga and graphql-codegen, so the release process (changesets) and CI are mature rather than one maintainer's side project. It can run as a standalone local aggregator or as an actual Federation subgraph, so it covers both the 'proxy one API' and 'gateway for many' use cases.
The README is pure landing-page copy — no code sample, no config snippet, nothing — so you have to leave the repo entirely to find out what a mesh.config.ts actually looks like. The config surface is large: codegen step, per-handler config, transform pipeline; the e2e folder alone has dozens of permutations, which means debugging a resolution problem can quickly turn into reading Mesh internals instead of your own code. Nothing in the README addresses the actual hard part of this kind of tool — N+1 fan-out across merged REST/gRPC/SOAP backends, or caching trade-offs when stitching multiple upstreams — even though there's a cache-control e2e test buried in the repo. Adopting Mesh in practice means buying into The Guild's broader toolchain (graphql-config, graphql-codegen) rather than pulling in a standalone library.