Monorepo / multi configuration
I'm working on various APIs that're living in a shared Git monorepo with common configuration. I'd like to have multiple Stellate configurations in the same repository that is integrated with gh-actions. My proposal is to add a configuration path to the stellate CLI: npx stellate push --config stellate-a.yml npx stellate push --config stellate-b.yml
I would love to be able to specify a rate limit for my origin so I can't get bombarded with requests!
Choose CDN location
That would be great to be able to choose the zone of the CDN. For example my app is only used in France, that would be great to have the guarantee that the CDN cache data are not far from there.
Allow for use of multiple claims in a single JWT scope
For example, cache by role and org. Right now, you would need to combine those and increase the token size unnecessarily.
Drain Stellate logs
I'd like to automate the extraction of the logs associated to my Stellate project to another place (like Amazon S3) more convenient for analysis, exploratory etc...
Allow purging the cache via the Metrics dashboard
It would be super helpful if when browsing by 'Operations' there were utility buttons that let you purge the cache for a given operation or data type. For example, if I could browse operations, see 'ResourceByDatabaseId' and then have an action from there to invalidate al caches for that query. I know I can look at docs to figure out how to write the query, etc., but this would be super helpful for us to make things easier/quicker.
Sorting on dashboard
Queries/mutations on the dasboard are currently sorted by "Count". It would be really useful to be able to sort them by "Response Time" or "Name/Query" as well. Having additional filters would also be useful, for instance: List all queries with "xyz" in name List all queries slower than 1s etc.
Allowlisting (persisted queries)
I'd love to allowlist the queries my actual app sends so malicious actors can't put together expensive queries manually!
When the API returns an error (especially "Unauthorized"), it should be cached. There's no point in hitting the API with the same request that returned such error again.
Directive based caching
We're currently using Apollo Server caching, where you decorate your schema with @cacheControl directives. Context: https://www.apollographql.com/docs/apollo-server/performance/caching/ Since we're already using it throughout our large schema, it would be nice if it was offered so we can keep the rules with the types definitions and not need to recreate a config to migrate from that to this