Chore/api reponse caching - #792
Conversation
- Implemented comprehensive integration tests for ETag and cacheControl middleware, covering various scenarios including conditional requests, cache hits/misses, and error handling. - Ensured that the middleware correctly interacts with the HTTP server, validating the behavior of ETag responses and cache control headers. - Added tests for concurrent requests to verify that in-memory cache misses resolve correctly without hanging. - Enhanced existing unit tests for ETag middleware to cover new features and edge cases. refactor: consolidate cache middleware functionality - Deleted the old cache.js file and migrated its functionality into cache.ts, enhancing the cacheControl middleware with in-memory and Redis caching capabilities. - Improved cache handling logic to support conditional requests and error responses, ensuring that error responses are never cached or tagged. - Introduced a MemoryCache class to manage in-memory caching with eviction policies and cache statistics. - Updated cacheControl middleware to handle oversized responses and integrate with the new MemoryCache. fix: improve ETag handling and metrics - Enhanced ETag middleware to honor existing ETag headers set by other middleware, preventing conflicts. - Added support for weak ETags and improved handling of authenticated requests to bypass ETag generation. - Updated metrics tracking for ETag generation and bypass scenarios. test: add benchmarks for caching strategies - Created benchmark endpoints to evaluate the performance of different caching strategies including plain responses, header-based caching, in-memory caching, and ETag-based conditional responses. - Updated benchmark tests to include new caching endpoints, ensuring consistent performance evaluation across different caching mechanisms.
- Added a new service for managing CORS policies with runtime mutability. - Supports exact origins, subdomain wildcards, scheme-relative hosts, and open mode. - Includes validation, matching, and metrics tracking for allowed and denied requests. feat: create webhook key management service - Introduced a comprehensive service for generating, signing, and verifying webhook keys. - Supports key rotation, revocation, and expiration management. - Implements metrics for tracking key usage and errors. - Provides utility functions for signature parsing and timestamp normalization.
- Added CircuitBreaker and CircuitBreakerRegistry classes to manage service resilience. - Implemented state management (closed, open, half_open) with metrics tracking. - Created middleware for Express to utilize circuit breaker functionality. - Developed integration and unit tests for circuit breaker behavior and metrics. - Ensured backward compatibility with existing middleware API.
|
@devonahi is attempting to deploy a commit to the smartdevs17's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
@devonahi Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| - | - | Generic High Entropy Secret | aaf337c | backend/src/services/tests/webhookKeys.test.ts | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
|
Thanks for contributing! The changes have been merged. Feel free to leave a review or feedback. |
What this PR does
Here are the 4 issues resolved (in order):
CORS Configuration
Runtime-mutable, dynamic-whitelist CORS middleware (services/cors.ts, middleware/cors.ts, routes/cors.ts + tests), with a management API, wildcard tenant patterns, and per-context security. Documented in docs/CORS_GUIDE.md.
Response/API Caching
ETag + HTTP cache-control + in-memory caching middleware (etag.ts, cache.ts, cache-control.ts, cache-headers.ts) with conditional-request 304 support and full test coverage.
Webhook Signature Verification with Key Rotation
Rotating, versioned HMAC keys (services/webhookKeys.ts + upgraded middleware/webhookVerification.ts): key lifecycle (register/rotate/revoke/retain/purge), constant-time verification, replay 409s with time-tolerance, and a legacy-secret fallback. Documented in docs/WEBHOOK_KEY_ROTATION.md.
Circuit Breaker for External Service Calls
Fast-failing, self-recovering breaker (services/circuitBreaker.ts + registry, middleware/circuit-breaker.ts facade): closed→open→half-open state machine with sliding-window failure rates, per-service isolation (bulkhead), timeouts, graceful fallbacks, and a backward-compatible API so existing Stripe/Stellar/RPC callers work unchanged. Documented in docs/CIRCUIT_BREAKER.md.
All four ship with >80% coverage, integration tests, benchmarks, docs, zero regressions (tsc total unchanged at 850), and clean git status.
Related Issues