How can I use Node.js worker threads with Next.js App Router Route Handlers in Next.js 13 with swc

[g17us3r]

I am using the Next.js 13.4 App Router and Route Handlers. I have a computation in a Route Handler that I do not want to run on the main thread and block the thread. I am running the application on Node.js and using the standalone build. I want to use a Node.js worker thread to run the computation. How can I do this with Next.js?

When I try and add a file such as my.worker.js and then import or require it in the route handler, Next.js build bundles it together with the route handler code and the worker file is not in the output directory and I cannot get that to work. After looking at the docs and googling, comnfiguring swc in Next.js seems to not be supported. I would like to not fall back to babel if at all possible.

I'm thinking of some hack to manually copy a worker file to the output directory and then try and construct a path to it and require in such a way that swc is unable to resolve the code at build time, so it won't try and bundle it.

Ideally, I would also use typescript, but to get it working with JavaScript is ok, just to get this working somehow.

[quintesse]

Hi, were you ever able to figure this out? I'm in the same situation of trying to use worker_threads from within Next.js.

[mr-tm]

Yes, there should be a separate example for server side worker_threads (with typescript). For now we have only example for client side web workers: https://github.com/vercel/next.js/tree/canary/examples/with-web-worker

Currently worker_threads is not working out of the box with worker.ts extension.

[devrayat000]

Worker Threads (which are server sided) and Web Workers (which are client sided) are not the same

[zero1zero]

Did anyone ever figure out a good pattern here? Been trying with Piscina, Threads.js and raw worker_threads with no luck. Similar sentiment: I'll settle for js but would prefer ts.

[sepehrsamavati]

This is my setup:

I am using yarn monorepo with two projects (two separate package.json). One project serves as the application's (sdk/core) layer, while the other project acts as the endpoint with a Next.js server and client. The endpoint project imports modules from the core project. Within the core project, I have a Piscina worker pool, and I need certain modules to be loaded within these workers.

However, Next.js minifies everything during the build process, including the core modules. This becomes problematic for any runtime code that relies on the 'currently running' file path, as it may break. In a production build, you can find the minified files at .next/server/chunks.
In my scenario, I have a copy of the core project in the production environment. To address this issue, I used process.cwd() (current working directory, which is the Next.js project), located the desired file from the core project, and loaded it into the Piscina worker pool.

By using process.cwd() and locating the required file from the core project, I was able to ensure the correct functioning of the Piscina worker pool in the production environment.

Example structure:

/
├── core
│   ├── src (typescript source)
│   │   ├── .../worker.ts
│   │   └── .../workerPool.ts
│   ├── dist (build)
│   │   ├── .../worker.js
│   │   └── .../workerPool.js
│   └── package.json
└── next
    ├── src
    ├── .next (next.js build)
    └── package.json
package.json (yarn monorepo)

Example workerPool.ts:

const worker = new Piscina({
    // load file from core project
    filename: path.resolve(process.cwd(), "..", "core", "dist", "someDirectory", "worker.js"),
});

[youyou-sudo]

using process.cwd() and locating the required file from the core project

Thank you so much! Using this method, you only need to add the Worker.js file to the directory where the built server.js is located. This is a great solution that doesn't require many changes to the code or directory structure.

Here is my use case for the reference of others who encounter the same issue.

---

I used standalone and worker_threads.

// next.config.js
odule.exports = {
  output: 'standalone',
}

// workerPool.ts
import { Worker } from "worker_threads";
import path from "path";

    const workerPath = path.resolve(
      process.cwd(),
      ".next/server/worker/worker.js"
    );
    const worker = new Worker(workerPath, { workerData: { ref } });

After running next build, place the worker folder containing worker.js into the directory where server.js is located, which is the standalone folder.

Running node .next/standalone/server.js will allow you to use worker_threads in the production environment.

[cutephoton]

Here's a clever pattern that will work with a node module. Might have to be careful in dev mode if it persists. I haven't looked into the implications of that or... any of the other implications of coloring outside of the lines. (My initial use was a fire-and-forget kinda thing. Works surprisingly well.)

import {
    Worker
} from 'node:worker_threads';

export interface WorkerOptions {
    package: string;
}

/**
 * Escaping webpack!.  :)
 */
export function newEscapeHatchWorker(opts:WorkerOptions)  {
    const escapeHatch = `
        (async () => {
            await import ("${opts.package}");
        })();
    `;
    return new Worker(escapeHatch, {eval:true});
}

[kalebmmm]

Okay, I think I found a solution that doesn't rely on any hacks and supports TypeScript.

As of writing this, Next.js uses Webpack 5, so you have to reference your worker file the Webpack 5 way:

new Worker(new URL('./my_worker.ts', import.meta.url))

Next, you need to update your next.config.mjs to override the server Webpack configuration. Specifically, we need to set the output publicPath to a blank string. By default, this value is /_next/ which means "the _next folder inside the root directory". This is great for HTTP URLs, but breaks filesystem references by pointing at C:\_next\... in Windows for example. The blank string will make URLs relative to your .next/server/ directory in the project.

const nextConfig = {
   ...,
   webpack: (config, { isServer }) => {
      if (isServer) {
         config.output.publicPath = "";
      }
      return config;
   }
};

export default nextConfig;

[infodusha]

I have figured it out that way:
Import:

const worker = new Worker(/* webpackChunkName: "transform.worker" */ new URL('./transform.worker.ts', import.meta.url));

postbuild:

find .next/server -name "*.worker.js" -exec mv {} .next/standalone/{} \;

[d3v-tushar]

Worked for me on NextJS 15.0.4 . Thanks

const worker = new Worker(/* webpackChunkName: "bulkpush.worker" */ new URL('./workers/bulkpush.worker.ts', import.meta.url));

// next.config
webpack: (config, { isServer }) => {
if (isServer) {
config.output.publicPath = "";
}
return config;
}

[Haaxor1689]

was anyone able to get this working in dev? in prod I got it working, I just need to manually copy the file

COPY --from=builder --chown=nextjs:nodejs /app/.next/server/chunks/uploadWorser.js ./.next/server/chunks/uploadWorser.js

[infodusha]

@Haaxor1689 for dev edit next config the way described above (and since that is a webpack do not use --turbo option)

[Haaxor1689]

oh yeah I forgot I was running in --turbo mode, ok it works in dev too now :) thanks

[FranckWebPro]

I made it work with typescript on localhost but I'm trying to put my app in production with Vercel and it doesn't work... maybe the worker thread aren't working at all with Vercel ?

[Haaxor1689]

Vercel kills your route handlers as soon as they return response. Only option is to call waitUntil but that still falls under the limitations of server function execution that is not sufficient for truly long-running tasks. Spawning workers is only possible in standalone deployment, for cloud deployment you need some 3rd party service.

[FranckWebPro]

Yes I finally deployed on Railway, my background jobs are way too long for serverless

[Haaxor1689]

So I'm running my NextJs instance in a docker container and need to execute a long-running tasks that uploads uploads bunch of files after getting "pinged" that update occurred. I'm trying to achieve this with a WorkerThread, since that should not have the inherent resource limitation of Next's route handlers. My current solution:

src/api/pushed/route.ts:

import { Worker } from 'node:worker_threads';

export GET = () => {
  new Worker(
    /* webpackChunkName: "uploadWorker" */ new URL(
      './uploadWorker.ts',
      import.meta.url
    ),
  );
}

src/api/pushed/uploadWorker.ts:

import { workerData } from 'node:worker_threads';

// Imports work just fine here, even import aliases

next.config.js

const config = {
  output: 'standalone',
  // ...other options
  webpack: (config, { isServer }) => {
    // Workaround to allow loading of Worker files
    if (isServer) config.output.publicPath = '';
    return config;
  }
};

Dockerfile addition:

# Copy workers
COPY --from=builder --chown=nextjs:nodejs /app/.next/server/chunks/uploadWorker.js ./.next/server/chunks/uploadWorker.js

Also for this to work in dev you need to disable --turbo.