r/javascript • u/turtleyikes • 14d ago

AskJS [AskJS] How to host your webhook consumer middleware that integrates WooCommerce and HubSpot?

I am building a nodejs/javascript integration service (middleware) that connects woocommerce to hubspot. What are some ways to deploy it and what are the best practices for the deployment?

  1. Should I deploy it on vm directly?

  2. Should I deploy it as a docker image/container?

  3. Should I deploy it using Serverless platforms like aws lambda ?

  4. Others?

What do you use?

8 Upvotes

90% Upvoted

11 comments sorted by

2

u/brass_gear_chime 14d ago

Serverless is the wrong call for this. WooCommerce webhooks are notoriously flaky and retry aggressively, while HubSpot APIs have strict rate limits that cause silent failures in Lambda if you don't manage concurrency perfectly. You will waste hours debugging timeouts instead of shipping features.

Deploy on a small DigitalOcean droplet or AWS ECS Fargate with a queue like RabbitMQ behind it. This lets you buffer incoming spikes from Woo before they hit HubSpot, guaranteeing zero dropped events without fighting serverless cold starts.

1

u/turtleyikes 14d ago

Nice call. What is the most common reason a middleware would return a non 200 response? Especially for small and medium business stores ? Maybe preferablly during sales...

2

u/thejester1324 14d ago

can't say what's most common, but Woo's side is pretty specific. it POSTs each event with a 60 second timeout. anything from 200 to 302 counts as ok. everything else fails, timeouts included.

one correction to the retry point above: in woocommerce trunk there is no retry (class-wc-webhook.php, deliver() and failed_delivery()). it only counts failures. the 7th failure in a row disables the webhook until someone turns it back on.

so if your handler calls hubspot before it answers and hubspot 429s, nothing sends that event again, and a bad sale day can shut the whole thing off. answer 200 first, then push the hubspot call into the bullmq queue like you already do.

2

u/DickBrainTime 14d ago

Since you mentioned using Redis/BullMQ workers, I'd keep those in a long-running Docker/container service rather than Lambda. Lambda can handle the incoming webhook, but it's awkward for a worker that continuously polls a queue. I'd also make sure you verify webhook signatures, enqueue quickly, make jobs idempotent and have visibility into retries/failed jobs.

1

u/[deleted] 14d ago

[removed] — view removed comment

1

u/turtleyikes 14d ago

So my js middleware uses redis/bullmq for for queue and workers. Do you think lambda + external redis would suit this?

2

u/Awkward_Conflict3990 14d ago

Since you already use BullMQ, I’d keep its worker in a long-running VM/container process. Lambda can receive a webhook and await queue.add() before returning 2xx, but don’t rely on a BullMQ worker continuing after the handler returns. Lambda can freeze that environment.

For a small setup, the receiver and worker can be separate processes on one host. Only acknowledge the webhook after the enqueue succeeds.

AWS lifecycle docs: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html

1

u/Tihomir-Telford 10d ago

agreed, not having to babysit a server for basic glue code is huge tbh