Remote: Yes

Willing to relocate: No

Technologies: Full-Stack and Dev-tools (Typescript, PHP, C#, React, Angular, WordPress, CLI, Web, Mobile, API, SQL, DevOps)

Résumé/CV: https://www.ar27111994.dev/resume/resume_full.pdf

Email: admin@ar27111994.dev

GitHub: https://github.com/ar27111994

Ahmed Rehan | Full-Stack Engineer | Devtools, Agent Systems, Automation, Webhooks & Performance-Conscious Products

I built *Webhook Debugger* because existing tools were either ephemeral (RequestBin) or required persistent tunnels (ngrok) that I couldn't leave running on a staging server.

*Repo*: https://github.com/ar27111994/webhook-debugger-logger

*The Stack*: Node.js, Express, Apify SDK (for storage/dataset abstraction), Docker.

*Key Technical Decisions*:

1. *Global SSE Heartbeat*: Instead of `setInterval` per connection (O(N) timers), we use a single global timer to flush heartbeats to all `res` objects. 2. *SSRF Protection*: Custom validator (`src/utils/ssrf.js`) that resolves DNS and checks against a blocklist (including AWS Metadata IP `169.254.169.254`) before forwarding/replaying requests. 3. *Resilience*: The Replay engine implements exponential backoff for `ECONNABORTED` errors, allowing it to handle "blips" when targeting local dev servers. 4. *Hot-Reloading*: A background poller reads the input JSON every 5s and dynamically updates middleware, rate limits, auth keys, and webhook counts without restarting the process. 5. *Platform Integration*: We encountered (and fixed in v2.8.7) a specific schema validation bug that only occurred in the platform UI, teaching us to lean on native storage exports rather than wrapping them in custom views.

It's open source (ISC). I'd love feedback on the *SSRF implementation* – ensuring users can replay to `localhost` (safe in dev) but not internal subnets (unsafe in prod) was a tricky balance.

Comments URL: https://news.ycombinator.com/item?id=46632472

Points: 1

# Comments: 0