Introduction

A Node.js server can wait for an external program to finish without blocking the event loop, but the client still needs a way to hear about the result. The real design question is not how to "pause" the browser. It is how the server should notify the client after the child process exits or returns output.

Run the External Program Asynchronously

In Node.js, external commands are usually started with the child_process module. The server can keep handling other work while the child runs.

1const { spawn } = require("child_process");
2
3function runJob() {
4  return new Promise((resolve, reject) => {
5    const child = spawn("python3", ["worker.py"]);
6    let stdout = "";
7    let stderr = "";
8
9    child.stdout.on("data", chunk => {
10      stdout += chunk.toString();
11    });
12
13    child.stderr.on("data", chunk => {
14      stderr += chunk.toString();
15    });
16
17    child.on("close", code => {
18      if (code === 0) {
19        resolve(stdout);
20      } else {
21        reject(new Error(stderr || `process exited with code ${code}`));
22      }
23    });
24  });
25}

That gives the server a promise that resolves when the external program finishes.

Push the Result to the Client With WebSockets

If the user should see the result immediately, WebSockets are a strong fit. The browser opens a persistent connection, the server starts the external program, and the server emits an event when the process ends.

Server example with Socket.IO:

1const express = require("express");
2const http = require("http");
3const { Server } = require("socket.io");
4
5const app = express();
6const server = http.createServer(app);
7const io = new Server(server);
8
9io.on("connection", socket => {
10  socket.on("start-job", async () => {
11    try {
12      const result = await runJob();
13      socket.emit("job-finished", { ok: true, result });
14    } catch (err) {
15      socket.emit("job-finished", { ok: false, error: err.message });
16    }
17  });
18});
19
20server.listen(3000);

Client example:

1const socket = io("http://localhost:3000");
2
3socket.emit("start-job");
4
5socket.on("job-finished", payload => {
6  console.log(payload);
7});

This pattern is clean because the client does not need to guess when the external process is done.

Use HTTP Plus Polling When Real-Time Push Is Unnecessary

If you do not want persistent sockets, another common design is:

1. client sends an HTTP request to start a job
2. server returns a job ID immediately
3. client polls a status endpoint until the job is complete

That looks like this on the server:

1const jobs = new Map();
2
3app.post("/jobs", async (req, res) => {
4  const id = crypto.randomUUID();
5  jobs.set(id, { status: "running" });
6  res.json({ id });
7
8  try {
9    const result = await runJob();
10    jobs.set(id, { status: "done", result });
11  } catch (err) {
12    jobs.set(id, { status: "failed", error: err.message });
13  }
14});
15
16app.get("/jobs/:id", (req, res) => {
17  res.json(jobs.get(req.params.id) || { status: "unknown" });
18});

Polling is simpler to deploy than WebSockets, but it adds delay and repeated requests.

Do Not Hold the Original HTTP Request Open Unless the Job Is Short

For very short commands, it can be fine to wait and return the output directly in one HTTP response:

1app.get("/run-once", async (req, res) => {
2  try {
3    const result = await runJob();
4    res.json({ ok: true, result });
5  } catch (err) {
6    res.status(500).json({ ok: false, error: err.message });
7  }
8});

That is the simplest option when the external program completes quickly. For long-running jobs, keeping the request open is brittle and often leads to timeouts or a poor user experience.

Choose the Notification Method Based on Job Duration

A practical rule is:

• if the external program finishes quickly, return the result in the same HTTP request
• if completion time is unpredictable, use WebSockets or job polling
• if many clients must observe the same job, store status centrally and let clients subscribe or poll

The notification pattern should match the latency and UX requirements of the feature.

Common Pitfalls

The biggest mistake is trying to write to the client from code that no longer has a valid response object or connection strategy. Another is blocking the event loop with synchronous process execution when an async child process would work better. Developers also keep long HTTP requests open for jobs that can run for minutes, which leads to timeouts and brittle reconnect behavior. If the result matters after the page is reloaded, you also need some persistent job state instead of only an in-memory callback chain.

Summary

• Run the external program asynchronously with child_process.
• Decide separately how the client will learn that the job finished.
• Use WebSockets for immediate server push.
• Use polling with a job ID when sockets are unnecessary or inconvenient.
• Return the result in the original HTTP response only when the external job is short.
• Store job state explicitly if the client may disconnect or reconnect later.