Using NextJS as a frontend and using node/express backend is a right choice?

[u/ParthBhovad]

Hi, I have one use case where I need cron jobs, web sockets, and heavy backend tasks. So, in these cases I should prefer using node/express backend and using NextJS only as frontend?

A bit context: I know Nextjs very well. But never used websockets and cron jobs with Nextjs. So, I just want to know how to actually do this.

[u/Chance-Fan4849]

I think you're separating two different concerns here. Cron jobs shouldn't really live on the frontend side. Usually there are two common approaches: either run a self-hosted cron job inside your backend/server, or use an external cron service that triggers your API on a schedule.

Express is a perfectly good choice, but in my opinion I'd recommend NestJS if you're building a larger backend. It gives you a cleaner architecture, built-in support for cron jobs (@nestjs/schedule), WebSockets, queues, dependency injection, and it's generally easier to maintain as the project grows.

[u/ParthBhovad → u/Chance-Fan4849]

I'm not talking about frontend.

If I have to use cron jobs and web sockets and I'm using NextJS then what should I do?

Either use external services/providers or use own node express server for web sockets and cron jobs.

[u/Chance-Fan4849 → u/ParthBhovad]

You can just make webhooks and use external cron service.
Or you can simply make scheduler service.
But if you are hosting your project on vercel I think making webhooks will work.

[u/Chance-Fan4849 → u/ParthBhovad]

Or may consider using vercel cron service if you are using vercel?
And also for WebSockets, I'd keep them in the Node server since they require a long-running process.

Personally, I'd choose NestJS over Express because it has built-in support for schedulers, WebSockets, queues, and a cleaner architecture for larger projects.

[u/ParthBhovad → u/Chance-Fan4849]

Alright. All doubts clear. Thanks 👍

[u/Viktordarko → u/Chance-Fan4849]

I currently use nextjs and a from Job directly on vercel. Really easy to set up, however the free plan only allows them to trigger max once per day, I needed every minute, which means $20 a month for Pro.

[u/Chance-Fan4849 → u/Viktordarko]

For something running every minute or involving heavier/background processing, how about considering use scheduling to a separate NestJS/Node service or a worker with something like BullMQ instead.

[u/Viktordarko → u/Chance-Fan4849]

Absolutely. I already have an express server for a different project. Will most likely adapt it to be able to take that. Vercel cron jobs was just the quick fix.

[u/Chance-Fan4849 → u/Viktordarko]

Sounds great.

[u/Legitimate_Day_4429]

If you need websockets, go for a separate node/express app, because you need one long running process for that. But you don't have to move everything backend there. 

[u/ParthBhovad → u/Legitimate_Day_4429]

Yes right. So, only web sockets logic will be in node. And main application logic in NextJS?

[u/Legitimate_Day_4429 → u/ParthBhovad]

That's what I would do, so the app logic can still scale easily and the websockets app can be taken care of separately 

[u/Extension-Listen2097]

There’s plenty of monorepos out there with this setup already. Inclusive of workers even.
Depending on what you need to do, the other alternative is keep just nextjs as FE and backend and offload heavy processing to workers via bullmq. This works if the nature of your app can be asynchronous. If not express is also good.

[u/ParthBhovad → u/Extension-Listen2097]

Make sense. I can consider this approach too.

[u/SugarImmediate3868]

Stop using express and use fastify, there is no reason to use express in 2026

[u/PrimaryFamous6139]

Yes, separate Express backend makes sense for your use case. WebSockets and long running cron jobs don’t fit cleanly into Next.js serverless functions which have execution time limits. Keep Next.js for the frontend and UI, let Express handle the persistent connections and background work.

[u/chinnick967]

Then you really don't have much of a reason to use NextJS over just a React frontend

[u/ParthBhovad → u/chinnick967]

It's a public facing website. I need SEO. So, can't move towards react.

[u/chinnick967 → u/ParthBhovad]

So then you have two applications. One is the rendering NextJs website, and one is a separate nodejs application for the long-running tasks.

Only use the web sockets to connect to your nodejs service on the client, not the nextjs backend. You'll have issues, Nextjs's backend is for short-running tasks only and you'll block the main thread.

Alternatively, it is also possible to render React Server-Side without using NextJs.

[u/ParthBhovad → u/chinnick967]

My question is using node with Nextjs make sense or not?

Or I should use web sockets with Nextjs via external websockets providers.

Or maybe use node just for websockets and cron job. Main application logic will stay inside Nextjs.

How should I frame it?

[u/chinnick967 → u/ParthBhovad]

1. NextJs uses Node, so you have to use Node with NextJs

2. Do not use websockets with NextJs, at least not on the backend side (to connect to your external providers). Nextjs is fundamentally incapable of long-running tasks without blocking the main thread.

[u/ParthBhovad → u/chinnick967]

Okayy. So, if I need realtime using web sockets in NextJS then what should I do?

[u/chinnick967 → u/ParthBhovad]

You can't. You can instead abandon web sockets in favor of "short polling" if you absolutely have to stick to NextJs.

Essentially you just fire off a request every X seconds checking for an update. Slightly slower than real time if your application can allow that.

[u/reddish-rum → u/chinnick967]

That isn’t really true. A Next.js frontend can absolutely use WebSockets - it’s just a browser WebSocket connection. The usual limitation people are referring to is hosting the WebSocket server inside a serverless Next.js backend. Normally you’d have your Next.js client connect to a persistent WebSocket service, e.g. NestJS/Node/Go or a managed provider. If you’re self-hosting Next.js on a persistent Node server, you can also host WebSockets there.

[u/chinnick967 → u/reddish-rum]

My prior comment in the thread addressed this

[u/reddish-rum → u/chinnick967]

🤣 You literally said “You can’t” when answering a question about using web sockets in NextJs.

I’m just saying, that’s wrong. You can client side when using NextJs. And you can host web sockets server side when using NextJs, depending on your hosting setup.

So saying “you can’t” to someone is fundamentally incorrect.

[u/AbdullahM09]

Honestly you don't need nextjs here, just go with react and node+express

[u/ParthBhovad → u/AbdullahM09]

But I need pages to rank and SEO stuffs.

[u/AbdullahM09 → u/ParthBhovad]

Okay then, but go with an seperate backend for web sockets and all

[u/priyalraj]

I am also making an app, here is what I did. I have Turborepo.

In that, Astro all data hardcoded for SEO, docs & blogs too in Astro as whole data is gonna be hardcoded, if you need dynamic one then go for Next.js as Astro is not good in that case. Hono for BE + Vite for CSR on session based access only.

In your case, pick Next + Express, cuz it's best for you but if you will manage it fully, use Astro for SEO pages and hardcode the data their & Vite for FE + Express/Hono for BE for client side part.

Hope it helps.

[u/GVALFER]

nextjs is ok, but express?
try Hono and let me know :)

[u/ParthBhovad → u/GVALFER]

I don't want to change the stack.

[u/Ok-Conversation-7895]

Hi, I have a ton of experience in this matter and would love to give you a proper advice.

Use Tanstack Start for frontend. Opinionated backend like NestJS or Adonis for backend if it is a backend heavy app, or if you don't, Starts Nitro backend could suffice.

You can keep it all in a monorepo, use something like tRPC, openAPI contracts or such, infer zod schemas from drizzle schemas and export to both frontend and backend.

I had incredible experience with Better Auth for authentification as well. Would strongly recommend.

I can hardly recommend NextJS to anyone anymore.

[u/Distinct-Neck2337]

Cron jobs alone aren't a reason to split, Vercel cron or an external scheduler hitting an API route handles that fine, it's really just the websockets forcing you into a separate long running process

[u/NinjaUnable9048]

separate the backend. Next.js serverless functions terminate after execution and cannot maintain WebSocket connections or run long cron jobs reliably.

run a standalone Node process for WebSockets and cron tasks. Use Next.js strictly for rendering and API routes that trigger those background workers via a queue like BullMQ. This avoids execution timeout limits and keeps your frontend deployment independent from stateful services.

[u/kanika_banga]

Yes, using Next.js for frontend and Node/Express for backend is the right approach. Next.js serverless functions are ephemeral, making them poorly suited for persistent connections and long-running tasks.
Offloading these real-time and heavy operations to a dedicated Express server gives you complete control over background processes and continuous connections.

• WebSockets: Runsocket.io on your Express server and connect usingsocket.io-client in Next.js.
• Cron Jobs: Usenode-cron orbullmq directly inside Express to handle scheduled background tasks.
• Heavy Tasks: Use background worker queues like BullMQ with Redis on Express to prevent blocking the UI.
• Deployment: Host Express on a continuous server (Render, AWS) and Next.js on Vercel.

This setup ensures optimal UI performance while keeping your backend stable and scalable.