Glossary
API key management
API key management refers to the practices and tools used to manage the lifecycle of API keys, which are unique identifiers used to authenticate requests made to an API (Application Programming Interface).
API subdomain
An API subdomain is a subordinate domains of a website or web application that is reserved especially for hosting APIs.
APQ
See Automatic Persisted Queries.
Automatic Persisted Queries
An automatic persisted query (APQ) allows GraphQL clients to send a unique hash of a query instead of the full query string. The server can then use this hash to look up and execute the associated full query.
Cache
A cache, in the context of GraphQL, refers to a mechanism for storing and reusing the results of GraphQL queries, in order to improve performance and reduce the load on the origin server. Caching can be done at the edge, using a CDN-like service like Stellate’s GraphQL Edge Cache. This allows caching of GraphQL queries close to the client, reducing latency and origin server load.
Cache Hit
A Cache Hit indicates the request was found in the cache and served from there.
Cache Hit Rate
The Cache Hit Rate (CHR) is a metric that indicates the ratio of hits to cacheable traffic. Stellate calculates the CHR using the following formula: Cache Hit Rate = Cache Hits / (Cache Hits + Cache Misses). the CHR metric allows you to understand and optimize your cache performance, which in turn can reduce the traffic to your backend.
CHR
See Cache Hit Rate.
Cache Miss
A Cache Miss indicates that the query was not yet cached and forwarded to your origin server.
Caching
GraphQL caching refers to the process of storing and serving GraphQL query responses from a cache, rather than fetching the data from the origin server every time. he goal of GraphQL caching is to reduce the load on the origin server, improve response times, and provide a more efficient and cost-effective GraphQL API for clients.
Cache invalidation
Cache invalidation refers to the process of removing or updating cached data when the underlying data changes, ensuring that subsequent requests receive the most up-to-date information. This is a critical aspect of caching, as it prevents serving stale data to users.
Cache Pass
A Cache Pass indicates a request that can not be served from the CDN and needs to be passed on to your origin server at all times.
Edge caching
Edge caching refers to the process of caching data at the edge of a network, closer to the end-user, to reduce the latency and load on the origin server. In the context of Stellate, edge caching involves caching GraphQL responses at Stellate’s globally distributed data centers, so that subsequent requests can be served directly from the edge, without needing to go back to the origin server. This helps improve the performance and scalability of GraphQL APIs.
Endpoint
A GraphQL endpoint refers to the URL or network address where a GraphQL API is accessible. It is the entry point for making GraphQL queries and mutations to retrieve or manipulate data.
Federation
GraphQL Federation is an architectural pattern that allows you to build a unified GraphQL API by combining multiple GraphQL services, called subgraphs. Each subgraph is responsible for a specific domain within the overall system. Federation simplifies the development and maintenance of complex GraphQL architectures by breaking them down into smaller, self-contained services. It promotes loose coupling between subgraphs and enables independent development and deployment. Federation also provides advanced features like automatic schema stitching, entity resolution, and distributed tracing for enhanced performance and flexibility.
Graph
A GraphQL graph refers to the data model and schema that defines the structure and relationships of the data available through a GraphQL API. It consists of types, fields, and the connections between them, forming a graph-like structure that clients can query to retrieve the desired data. The graph represents the complete set of data and operations that a GraphQL API exposes to its clients.
GraphQL
GraphQL is a query language and runtime for APIs that provides a more efficient, powerful, and flexible alternative to traditional REST APIs. It allows clients to request exactly the data they need and no more, reducing the amount of data transferred over the network. GraphQL APIs expose a schema that defines the available data types and the operations that can be performed on them, enabling clients to query the data they require in a declarative manner.
GraphQL Schema
A GraphQL schema refers to the overall data model and structure that defines the types, fields, and relationships available through a GraphQL API. It represents the complete set of data and operations that a GraphQL API exposes to its clients, forming a graph-like structure that clients can query to retrieve the desired data.
Invalidation
See Cache invalidation.
Key field
A GraphQL key field refers to the field that holds the unique identifier for a particular node type in a GraphQL schema. Stellate needs to know which field acts as the key or unique identifier in order to properly manage cache invalidation and purging. Knowing the key fields is crucial for Stellate to be able to invalidate cached data when the underlying data changes.
Logging token
A GraphQL logging token refers to a unique identifier that is used to associate a Stellate service with the logging and metrics data collected for that service. The logging token is a required configuration setting when integrating Stellate with a GraphQL API, as it allows Stellate to properly track and report on the usage and performance of the API.
Mutation
A GraphQL mutation is a type of GraphQL operation that represents a write operation, as opposed to a query which represents a read operation. Mutations in GraphQL can’t be cached because they represent write operations. As a result, mutation requests are sent directly to the origin server and receive a PASS status from the Stellate Edge Cache, rather than being cached. Mutations are used to create, update, or delete data on the server, whereas queries are used to retrieve data.
Partial query caching
Partial Query Caching is a feature offered by Stellate that allows you to optimally cache your existing GraphQL queries. It works by splitting any given query into multiple separate cache entries, each with its own caching characteristics such as max-age, stale-while-revalidate, and scopes. This enables you to cache more of your queries, reduce the load on your origin server, and improve the overall efficiency of your GraphQL API.
Persisted Query
A persisted query is a GraphQL optimization technique where the full query string is replaced with a unique identifier. This helps reduce network overhead and improve performance by allowing clients to send the identifier instead of the entire query.
Purging
GraphQL Edge Caching purging refers to the process of invalidating or clearing the cached responses stored in the Stellate edge cache. Stellate provides two methods for purging the cache, automatic purging and manual purging. The purging process ensures that the cache is kept up-to-date and provides users with the most recent data, especially when changes are made to the underlying data in your GraphQL API.
Payload
A GraphQL payload refers to the data that is returned in response to a GraphQL query or mutation. It includes the requested fields and their corresponding values, as well as any errors that may have occurred during the execution of the request. The payload is typically returned as a JSON object, with the requested data nested under a “data” field, and any errors nested under an “errors” field.
Query
A GraphQL query is a request sent to a GraphQL server to retrieve data. It is written in the GraphQL query language and specifies the data that the client wants to retrieve, including the fields, types, and any necessary variables. This allows for efficient data fetching and reduces the amount of data transferred over the network.
Query normalization
GraphQL query normalization refers to the process of transforming similar GraphQL queries into a consistent format before sending them to the server or caching them. This ensures that equivalent queries can be recognized as the same, allowing for more effective caching. Query normalization is typically a client-side operation, where the client is responsible for normalizing queries before they are sent to the server. This helps improve the performance and efficiency of the GraphQL API by enabling better cache utilization.
Rate limiting
Rate limiting is a mechanism to protect GraphQL APIs from excessive traffic or abuse. It allows you to set limits on the number of requests per minute, hour, or day, preventing potential attacks such as Distributed Denial of Service (DDoS). The Rate limiting feature counts the number of requests, and has more advanced capabilities to limit based on specific queries, mutations, or custom consumer identifiers like JWT tokens.
Resolver function
A GraphQL resolver function is a function that is responsible for fetching the data for a specific field in a GraphQL query. The resolver function takes in the parent object, arguments, context, and info parameters, and returns the data that should be included in the response for that field.
Response header
A GraphQL response header is additional information that Stellate adds to the response when a request passes through our service. Some key response headers mentioned include: stellate-cache, stellate-cache-key, stellate-cache-ttl, and the stellate-cache-scope. These headers provide developers with insights into how the Stellate edge cache is handling their GraphQL requests and responses.
Scopes
Scopes allows a web application to have different authentication mechanisms and settings for different parts or functionalities of the application. This provides a way to manage and enforce access control and security policies based on the specific requirements of each scope.
Subdomain
A GraphQL subdomain refers to a self-contained GraphQL service that provides a subset of the overall data for a specific domain within a larger, federated GraphQL system. It is responsible for handling a particular part of the data and schema. The subdomain acts as an isolated unit that can be independently developed, maintained, and scaled. It contributes to the overall supergraph by providing its specific functionality and integrating with other subdomains to form a cohesive GraphQL API that clients can query.
Subgraph
A subgraph is a self-contained GraphQL service that provides a subset of the overall data for a specific domain within a larger, federated GraphQL system. Each subgraph is responsible for a particular part of the data and schema.
Supergraph
A supergraph is the composite GraphQL schema that is formed by combining multiple subgraphs. It represents the complete unified GraphQLAPI that clients can query. The supergraph is responsible for routing and delegating client queries to the appropriate subgraphs, aggregating the results, and presenting a cohesive API to the client.
stale-while-revalidate
This is the time when a stale result from the cache is still served, while updated data is fetched from your origin servers in the background.
swr
We welcome suggestion for additional glossary terms.