Use Cases
The underlying problem that requires a supergraph:
- Consuming data from multiple places requires integration or aggregation work
- This increases the burden on the producer since it takes time to build and is fragile
- The problem is combinatorially complex when there are multiple producers and multiple consumers
Here are some common scenarios which point to the need of a supergraph:
- You're starting to evaluate the need of a federated data access layer
- API consumers wish they had a monolithic API view of their microservice APIs
- API consumers want GraphQL, but API producers don't want to maintain GraphQL services
- You're trying to add API integration or orchestration capabilities to your API gateway
- You're thinking about API standardization for creating flexible data APIs
- You want to replace direct database access with APIs
- You want to deliver data products or a data mesh over an API
- You want to create a knowledge graph and enable data retrieval for AI applications
In all of the situations above, the key problem is the lack of a strategy and an architecture to operationalize the strategy:
- API consumers are frustrated by the lack of APIs that are optimized for their specific data retrieval use cases
- API producers are not willing to take on the burden of maintaining and operationalizing API aggregation and composition problems
- There is no operating model or ownership model for who should solve the integration problem