GraphQL is a query language for your API, and a server-side runtime for executing queries using a type system you define for your data. Some of the advantages include:
- Flexibility: Clients request exactly what they need, and the API can evolve without breaking existing clients.
- Efficiency: Multiple resources can be fetched in a single request, reducing the number of requests and the amount of data transferred over the network.
- Strongly Typed Schema: The API’s type system is defined by a schema using GraphQL’s Schema Definition Language (SDL). This schema acts as a contract between the client and the server.
- Introspection: The schema serves as documentation and clients can query the schema itself, which makes it easier to understand the API and its capabilities.
GraphQL Federation is an architecture model that allows multiple GraphQL services, known as subgraphs or federated services, to be combined into a single schema or API. It consists of:
- A collection of subgraphs (usually represented by different back-end services) that each define a distinct GraphQL schema
- A gateway that composes the subgraphs into a federated data graph and executes queries across multiple subgraphs
Who is it for?
GraphQL is designed for:
- Developers and architects who are building APIs that need to be flexible, efficient, and well-documented.
- Teams that want to provide a rich and intuitive API experience for their clients.
- Organizations that need to manage complex, distributed systems with multiple back-end services.
GraphQL is particularly useful for:
- APIs that need to evolve frequently: GraphQL’s flexible query system allows clients to request exactly what they need, even as the API changes.
- APIs that need to be efficient: GraphQL’s ability to fetch multiple resources in a single request can significantly reduce network traffic.
- APIs that need to be well-documented: GraphQL’s schema definition language provides a clear and concise way to define the API’s structure and capabilities.
GraphQL Federation is designed for:
- Organizations with large, complex systems that are composed of multiple microservices or back-end services.
- Teams that need to manage and coordinate multiple GraphQL APIs.
- Developers who want to create a unified API experience for their clients, even if the underlying data is spread across multiple services.
How to use it?
For complete list of gateway endpoints, see – Endpoints (and other important links)
| Entity | Link | Details |
|---|---|---|
| Galileo/CL Gateway | Lower/STG – https://gw.api-stage.dh.comcast.com/galileo/graphql Prod – https://gw.api.dh.comcast.com/galileo/graphql | 1. Galileo GW accessed through Kong APIGW endpoint: Client => Kong => Galileo => Adapters => Upstreams 2. Use PRODUCTION SAT |
| Napier Schema Registry | https://napier-registry.apps.cloud.comcast.net/graphql | Use PRODUCTION SAT |
| Cartographer UI | https://napier-registry.apps.cloud.comcast.net/ | Refer Cartographer UI to onboard access |
| Schema Repository | https://github.comcast.com/cmt/fts-schema-registry/tree/clx%40dev | You can find the SubGraph, SuperGraph schemas, & endpoint configuration here. Each branch indicates the graph@env. All changes are managed/composed by the Napier API. |
| GraphVinci Visualizer | https://graphvinci.g3.app.cloud.comcast.net | GraphQL Browser to introspect, visualize graph, format/send queries etc. |
| Grafana Metrics | https://cmtfts-grafana-1.monitoring.comcast.net:3000/d/VFyb6577k/aws-apollo_metrics?orgId=1&var-Region=us-east-1&var-Application=galileo&var-Env=cl-prod-east | Env filters: 1. us-east-1 / galileo / cl-prod-east 2. us-west-2 / galileo / cl-prod-west |
in Philadelphia
