ardatan/graphql-mesh

🕸️ GraphQL Federation Framework for any API services such as REST, OpenAPI, Swagger, SOAP, gRPC and more...

View on GitHub ↗Jump to charts ↓Open shareable report →

Summary Information

Updated 12 minutes ago
Added to GitGenius on September 19th, 2026
Created on January 13th, 2020
Open Issues & Pull Requests: 177 (+0)
GitHub issues: Enabled
Number of forks: 363
Total Stargazers: 3,511 (+0)
Total Subscribers: 31 (+0)

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 36
New in 7 days: 0
Closed in 7 days: 0
Avg open age: 996 days
Stale 30+ days: 35
Stale 90+ days: 35

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

  • legacy (4)
  • bug (2)
  • documentation (2)
  • legacy-mesh (2)
  • stage/1-reproduction (2)
  • waiting-for-answer (2)
  • feature (1)
  • kind/bug (1)

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

GraphQL Mesh is a GraphQL Federation framework and gateway that unifies access to non-GraphQL services and databases through a single GraphQL interface.

The tool solves the problem of querying disparate backend systems—REST APIs, gRPC services, databases like MongoDB and PostgreSQL, and legacy systems using SOAP or OpenAPI specifications—without rewriting them as GraphQL services. It works by collecting API schema specifications from source services, creating a fully-typed SDK for each, converting those specs to GraphQL schema, applying custom transformations, and exposing the result as either a local GraphQL schema or a Federation subgraph. This allows developers to query heterogeneous backends with GraphQL queries and mutations while maintaining type safety.

Teams should adopt this tool when they need to integrate multiple non-GraphQL services into a unified API layer without modifying those services themselves. It suits architectures where some services are GraphQL-native and others are not, or where legacy systems must coexist with modern APIs. The tool is particularly valuable for organizations with REST, gRPC, SOAP, or database backends that want to offer a GraphQL interface to consumers. It can run as a local schema within an application or be deployed as a gateway layer between clients and internal services.

The project maintains an active contribution workflow with a documented contributor guide and code of conduct. Development activity shows ongoing engagement with schema transformation capabilities and support for multiple source API types. The maintainers actively welcome bug fixes and feature requests from users.