feat: reduce cold start latency for serverless functions#426
Conversation
- Lazy Sentry profiling: defer @sentry/profiling-node native addon load until after server.listen() via setImmediate, saving ~30-50ms on cold start - Deferred background services: jobs, BullMQ scheduler, queue processors, webhook worker, batch processor, and Redis connection all start after the server is already accepting requests (inside listen() callback) - Lazy sandbox initialization: SandboxManager, MockPaymentProcessor, and TestDataSeeder constructed on first use via getter functions, not at module scope - Fixed import ordering: all imports moved to top of file (ESM requirement), removed mid-file import that was between route registrations - Added missing gdprRouter import that caused a ReferenceError at runtime - Removed dead imports: SecurityMiddleware, SecurityMonitor, sanitizeInput, contentSecurityPolicy, rateLimitAnalyticsRouter, sessionsRouter, stripeRouter, signaturesRouter were imported but never used workers/src/index.ts: - Code splitting via classifyRoute() + getHandler() with handler cache for execution context reuse across requests in the same isolate - Cold start detection: isFirstRequest flag captures init duration on first request and persists to KV for the monitoring dashboard - Warm-up scheduling: scheduled() export handles Cloudflare cron trigger, proxies to backend /api/v1/cold-start/warmup every 5 minutes - Warmup proxies to backend so backend lastRequestAt is updated correctly workers/wrangler.toml: - Added cron trigger every 5 minutes for warm-up scheduling backend/src/lib/lazy-loader.ts (new): - lazyLoad(), lazySyncLoad(), trackedLazyLoad() utilities for deferred module initialization with a registry for the monitoring dashboard backend/src/middleware/cold-start.ts (new): - Per-request cold start tracking middleware with p50/p95/p99 latency - Detects first-request and idle-gap cold starts, records init duration - Fixed idle-gap initDurationMs to report actual gap duration backend/src/routes/cold-start-monitor.ts (new): - GET /api/v1/cold-start/metrics - full snapshot, p95 target compliance - GET /api/v1/cold-start/summary - lightweight dashboard summary - POST /api/v1/cold-start/reset - reset counters - POST /api/v1/cold-start/warmup - warm-up ping endpoint for schedulers
|
@od-hunter is attempting to deploy a commit to the smartdevs17's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
@od-hunter 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 | |
|---|---|---|---|---|---|
| 15742864 | Triggered | Generic Password | aea1ca4 | .github/workflows/migrations.yml | 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.
2 participants
Closes #385
#385