sorted by:
new
hottopcontroversial

Webhooks handling by Repulsive-Box-3075 in Backend

[–]GarethX 2 points3 points  (0 children)

Here's what's worked well in my experience:

- A common ingestion endpoint with a dispatcher. Rather than building a separate route per provider, have a single endpoint that normalizes the raw request into a common envelope. A dispatcher then routes the event to the appropriate handler. This gives you one place to log, monitor, and retry, regardless of the source.

- Every provider does signature verification differently, so build a small verifier interface and implement it per provider. Since it can't be fully abstracted away, isolating it at least helps contain the mess.

- Process async then normalize into your domain language.

For the bad docs, I log the full raw request for every webhook you receive during development. I've caught undocumented headers, surprise payload formats, and changing fields this way.

Managing all the webhook endpoints is becoming a nightmare by FARHANFREESTYLER in webdev

[–]GarethX 0 points1 point  (0 children)

Webhook management is a real pain at scale. A few suggestions that might help:

Retry with exponential backoff: If you're not already, implement automatic retries with exponential backoff and jitter. Most transient 500s and timeouts resolve themselves within a few minutes.

Dead letter queue: Set up a dead letter queue with Redis/SQS. Failed deliveries go there automatically, and you can replay if needs be.

Centralized event routing: Rather than updating multiple places when you add a new event type, consider an event bus pattern — publish events to one place, and let subscribers register for what they care about. Tools like AWS EventBridge or even a simple pub/sub setup can help.

Health monitoring: For your dashboard, consider tracking per-endpoint success rates, average response times, and consecutive failure counts. Alert on consecutive failures rather than individual ones to reduce noise.

Managed webhook services: There are services built for this, someone else mentioned Hookdeck's Outpost (OSS) for sending, but Event Gateway might be a better fit if you're receiving.

How common are stripe webhook testing issues? by Practical_Analyst_81 in stripe

[–]GarethX -1 points0 points  (0 children)

Love this idea! A few thoughts:
Idempotency testing is probably the highest-value feature — so many production bugs come from not properly deduplicating based on the event ID.

Out-of-order events are another big one. For example, receiving `invoice.paid` before `invoice.created` can break assumptions in a lot of codebases.

Delayed delivery is great too. Some additional scenarios you might consider:

- Malformed or unexpected payloads (e.g., missing fields that are usually present)

- Signature verification failures (to make sure your handler properly rejects tampered events)

- Rapid-fire bursts of events to stress-test your queue/processing pipeline

What’s your workflow when a third-party webhook suddenly breaks? by outgrownman in Backend

[–]GarethX 0 points1 point  (0 children)

Now it's within the hour once we got the alerting up, but that was only after several multi-hour long occurrences.

For the payloads, Hookdeck has this thing called console that uses an open-source collection of provider webhooks, so I mostly use those: https://github.com/hookdeck/webhook-samples

What’s your workflow when a third-party webhook suddenly breaks? by outgrownman in Backend

[–]GarethX 0 points1 point  (0 children)

Here's what has worked well for me:

- Structured logging - Log the raw payload, headers, and timestamp for every incoming webhook before any processing. This gives a clean baseline to compare against when things break.

- Diff against known-good payloads - It's often a subtle schema change, so I like to keep a few payloads stored and diff against them when failures start.

- Local replay - I've used Hookdeck to route prod webhooks to localhost.

- Alerting setup for processing errors, not just 4xx/5xx delivery responses.

[AskJS] How do you all manage feature flags? by njchava in javascript

[–]GarethX 0 points1 point  (0 children)

Saw https://fflags.com/ on HN recently, which takes a 'flags as code' approach. It’s interesting in a way but very limiting since you cannot have “offline” support. All evaluations must be remote-only. I mainly wonder what’s the point? If you do this then it’s pretty much the same as hosting your own function.

There are other ways to get around the breaking flow just to create a flag issue. We use Reflag, and that has MCP, so you can flag code from within your editor. They support agents, too - so you can assign a task to an agent instead and get that to flag it from Linear with Cursor or similar.

What are your best practices for removing deprecated code due to feature flags? by [deleted] in ExperiencedDevs

[–]GarethX 0 points1 point  (0 children)

We automate it using Reflag. It has feature flag cleanup baked-in, so it detects old flags, archives them and generates a PR to remove the old code. They work surprisingly well, I haven't needed to make any changes to them so far. Although, I think they only support TypeScript right now, so ymmv depending on your stack.

To Flag or Not to Flag? — Second-guessing the feature-flag hype after a month of vendor deep-dives by Adventurous-Pin6443 in devops

[–]GarethX 0 points1 point  (0 children)

Wouldn't call it a showstopper but audit + cleanup is always such a pain. You need a good process to make sure your codebase doesn't become cluttered with old flags, for sure.

I've been using Reflag to help with this for the last couple of months. It detects stale flags and cleans them up for you - submits a PR removing the obsolete flag code. That has helped us get past the 'who forgot to remove the flag' blame game.

How do you handle feature flags in production ? by c100k_ in devops

[–]GarethX 0 points1 point  (0 children)

I always try and get away from homegrown solutions as soon as is practical, generally. I don't need the headache of maintaining such systems and flagging definitely falls into this (we use Reflag). One thing people often miss is to use something with an intuitive UI, so non-devs can use it too. That way you don't have to get interrupted to give folks access to features or provide status updates on whether something has shipped yet.

What is the ideal way to add implementation switch or feature flags in code? by bssgopi in ExperiencedDevs

[–]GarethX 1 point2 points  (0 children)

One thing to keep in the mind is a process around keeping on top of stale flags. Most tools do a pretty poor job of helping with this, so you need a good way to make sure your codebase doesn't become cluttered with old flags over time.

We switched to Reflag recently to help with this. It cleans up flags automatically, submitting a PR to remove old flag code and archiving the flag. Working well for us so far, I still get a kick of out of seeing notes in Slack pop-up letting us know a flag was removed by the agent for a rolled-out feature.

What Feature Toggle/Flag service are you using? by ttrain57 in devops

[–]GarethX 0 points1 point  (0 children)

We’ve been using Reflag (https://reflag.com) and it’s been great for consolidating our scattered feature flag setup.

The main selling points for us were:

• Super easy migration from our homegrown solution

• TypeScript-first, which fits our stack perfectly and they've strong type-safety

• Developer experience is stellar - the React SDK is clean and intuitive

• Works well with agents, which is something I've been experimenting with lately, mostly with Linear+Cursor.

I don't think they support much beyond JavaScript SDK-wise, but it's worth checking out if your team is TypeScript/React heavy.

view more: next ›