Add Support for Webhook Auth Caching in DDN to Improve Performance

Is your proposal related to a problem?

This limitation can lead to performance issues and higher latency in authentication workflows, especially for use cases where the webhook response doesn't frequently change. Without caching, the same webhook request is sent repeatedly, even if the data remains constant for a period.

Describe the solution you'd like

I propose adding support for webhook auth caching in v3. This feature would allow users to configure caching for webhook responses based on a configurable time-to-live (TTL). It would follow the same principles outlined in the Hasura 2.0 documentation.

The implementation could include:

• A cache_control section in the metadata for the webhook configuration, allowing users to set a TTL.
• Clear documentation and examples for configuring the caching mechanism.
• Logs and metrics to monitor cache hits/misses and understand the impact of caching on performance.

Describe alternatives you've considered

1. Manual Caching Layer: Implementing an external caching layer in front of the webhook endpoint to handle caching manually. This approach is cumbersome and shifts the responsibility to the user, increasing implementation complexity.
2. Disabling Frequent Webhook Calls: Reducing webhook frequency by re-evaluating the authentication design, but this may not be feasible for all use cases, especially when real-time validation is required.
3. Sticking with Non-Cached Auth: Continuing without caching, which leads to unnecessary overhead in repeated webhook calls and slower performance for authenticated queries.

Adding native support for webhook auth caching in DDN would significantly simplify implementation and improve the overall developer experience.

Start by reading the linked Hasura 2.0 webhook-auth caching documentation and investigating how webhook configuration is represented in DDN metadata. The proposal calls for configurable TTL caching, documentation and examples, and cache-hit/miss logs and metrics; done would mean defining and implementing that support, but this issue does not identify code entry points or tests.