MICROSIVE

Node.js development for integrations, webhooks and bots

Most backend work is waiting: on a database, on another company’s API, on a carrier’s webhook. Node.js is good at waiting on many things at once and weaker at heavy number-crunching.

Reviewed by: Rahul Jaiswar, founder

What Node.js does

Node.js runs JavaScript on a server instead of in the browser. It handles many connections on a single event loop, which suits programs that spend most of their time waiting on networks and databases.

Is Node.js a good choice for connecting a WMS to other systems?

Usually, yes. Moving orders, receipts and shipment events between a warehouse system, a carrier and an accounting tool is mostly waiting on other APIs, which is the work Node.js does best. What it can connect to depends on each system: its API, its webhooks, or a scheduled file export. The system handoffs page covers what we build for that problem.

Where we use it

Microsive ATS, the recruitment software we built and run, runs on Node.js, and so do our messaging bots. Bots built to order sit under voice agents and AI bots.

What we check

We check that the same webhook arriving twice does not create two records. Providers resend anything they think failed, and without that check one shipment event or one message can land twice.

Where Node.js fits

  • Input and output work: REST APIs, webhooks from carriers and software vendors, bots holding many conversations at once.
  • A TypeScript front end, so types and validation code can be shared.
  • Background jobs pulled from a queue.

Where Python fits better

CPU-heavy jobs, such as large PDF batches, image processing or model inference, block Node’s event loop and slow every other request on that process. Jobs that lean on data-cleaning or machine-learning libraries usually belong in Python.

A hosting note

A bot has to stay connected. Platforms that put idle processes to sleep, or that only run short functions, break long-lived connections, so bots need hosting that keeps the process running. Railway is one way to do that.

Four questions for your Node.js developers

  1. What stops one slow request from holding up the rest?
  2. If the process restarts partway through a sync, what happens to the records it was moving?
  3. How are errors collected, and who gets alerted?
  4. How are npm packages reviewed before an upgrade?

What breaks Node.js services

  • Duplicate webhooks. Providers retry deliveries they think failed. Give each handler an idempotency key, so a retried “delivered” event can’t close the same shipment or bill the same line twice.
  • Unhandled promise rejections. One missed catch can stop the process. Add a process supervisor and error tracking from the first release.
  • Memory creeping up in long-running bots. Session caches that only grow eventually run out of memory. Give every cache a limit and an expiry.
  • Supply-chain risk. One install can pull in hundreds of packages. Commit the lockfile and run an audit before each release.

To commission an app with a Node.js backend, see software and web apps.

Have systems that need to talk to each other?

List them, and say which ones offer an API or an export. Someone from our team replies within one business day.

List your systems