HTTP services
REST APIs with Express or Fastify, or NestJS when the project is large enough to benefit from its structure and dependency injection.
Web & Application Development
Servers, Hosting & DevOps
AI & Automation
Performance, Security & Care
Web & Application Development
Node earns its place when a service is I/O-heavy or needs to hold open connections, real-time dashboards, chat, webhook processing, streaming responses from an upstream API. It is also the pragmatic choice when the team already writes JavaScript and a second language would just add friction.
The part that catches people out is not writing the code, it is running it. An unsupervised Node process that exits on an unhandled rejection, no log rotation, and no memory ceiling will take a site down at 3am. Production Node is as much an ops job as a development one.
How I work on it
Adjusted to the job, but this is the shape it usually takes.
If the workload is CPU-bound batch processing, Node is often the wrong tool and I will say so early.
API shape and error format agreed up front, documented with OpenAPI so the frontend can build against it in parallel.
Timeouts, retries and circuit breaking on every outbound call. Third-party APIs go down; the service should degrade rather than hang.
Nothing goes live without process management, log rotation and a restart policy.
Questions
systemd if the box is yours and you want one supervision mechanism for everything on it. PM2 when you need clustering, zero-downtime reloads and per-app log handling without writing unit files. Both are fine; running neither is not.
Yes, though I will ask what problem it is solving. GraphQL is a good fit when many different clients need different shapes of the same data. For a single frontend, REST with well-chosen endpoints is usually less machinery for the same result.
Yes, and it is a common setup, nginx or Apache in front, PHP-FPM handling the main site, Node running on an internal port behind a reverse proxy for the API or real-time piece.