This would allow people to use PagerDuty to get notified when an alert triggers.

I'd like to monetize my GraphQL API and have Stellate take care of as much as possible in this process. That includes the metrics to know how much a user of my API used the API.

I'd like to add a custom header to identify my request coming from different tenants/environments, to simplify filtering/exploration on this specific fields. For instance, I'd like to be able to filter on queries cached at environment/tenant level. For instance, adding to the cached payload, custom keys such as: x-adog-environment x-adog-tenant

As a user I want to pre-populate the edge cache so every user (including the first one) gets a fast reply from the cache.

I would like to rate limit my GraphQL queries by their complexity. A query that returns 1000 entities is more costly than a query that returns 5.

It comes up in our pen testing and I don't see a way to turn it off.

In order to connect to solutions like https://github.com/prometheus/alertmanager , we can expose a general webhook interface, which allows anyone to build their own alert pipeline.

In some cases, the authenticated data is subject related and when a new token is being issued for the user, the token is supposed to belong to the same user. For now it's not possible to validate an asymetric authorization token on GraphCDN side because it'd require to use the issuer public keys endpoint (e.g.: https://id.acme.com/.well-known/jwks.json ). Having the ability to configure such endpoint from GraphCDN's end would permit to validate dynamically tokens while leveraging the cache benefits.

It would be great if GraphCDN could propagate cache updates into all regions automatically. For example: A user in some region makes a request to a GraphCDN endpoint which results in a cache miss. GraphCDN gets the data from the origin and adds it to its cache not just in that region, but in all regions. That way, when another user in some other region makes the same query, they benefit from that cached response.

If the headers contain a request id, like x-request-id it'd be useful for debugging/tracing purposes to associate it to the log