Next.js + Node.js: Where Do You Draw the Line?

Kane Lim — Fri, 28 Aug 2026 14:52:37 +0000

I've been building a few applications with Next.js and Node.js, and one thing I keep coming back to is:

How much backend logic should actually live inside Next.js?

At first, the answer seemed obvious.

Next.js gives you Server Components, Route Handlers, Server Actions, middleware, caching, and a lot of other backend-like capabilities. For a small application, keeping everything inside one Next.js project is incredibly convenient.

But as the application grows, the architecture becomes less obvious.

For example, I've found myself asking:

Should authentication logic stay inside Next.js or move to a separate Node.js service?
When should a Route Handler become a standalone API?
Are Server Actions a good choice for business-critical mutations?
Where should background jobs and long-running tasks live?
How do you handle WebSockets or real-time events cleanly?
Should database access happen directly from Server Components?
At what point does a separate Node.js backend actually become worthwhile?

One approach I've used is essentially:

Next.js
├── UI
├── Server Components
├── Server Actions
└── Route Handlers
↓
Database

It's simple, fast to develop, and there are fewer moving parts.

But I can also see the argument for:

Next.js
↓
Node.js API
↓
Database / Redis / Queues

The second architecture gives you more separation and flexibility, but it also introduces more infrastructure, deployment complexity, authentication concerns, and places where things can fail.

That's where I'm currently trying to find the right balance.

My current thinking

I'm starting to believe the question shouldn't be:

"Is Next.js capable of being the backend?"

It obviously is for many applications.

The better question might be:

"What responsibilities will become painful if they remain inside the Next.js application?"

For a small SaaS, I'd probably keep things together until there is a concrete reason to split them.

For a system with heavy background processing, multiple clients, complex APIs, real-time communication, or independent scaling requirements, a dedicated Node.js service starts making much more sense.

But I'm curious what other developers are seeing in production.

Where do you draw the line between Next.js and a dedicated Node.js backend?

And if you've migrated from a Next.js-only architecture to Next.js + Node.js, what problem actually forced you to make the change?

I'd especially like to hear experiences from people running this setup at scale rather than just theoretical architecture opinions.

Mobile Development Is Changing Fast — Is React Native Ready for What’s Next?

Kane Lim — Thu, 27 Aug 2026 11:19:54 +0000

Mobile development isn’t just about building an app that “works” anymore. Users expect speed, smooth animations, reliable offline behavior, secure data, accessibility, and a consistent experience across devices all while development teams move faster than ever.

That’s one reason I’m excited about React Native.

React Native has evolved far beyond its early reputation as simply a way to share code between iOS and Android. With modern architecture, improved performance, better native integration, and a growing ecosystem, it’s becoming a serious choice for teams that want to move quickly without sacrificing the native experience.

What I find especially interesting is the balance between cross-platform development and native capabilities.

You can build most of an application with JavaScript/TypeScript and React Native while still going deeper into Swift, Kotlin, or native modules when the product actually needs it.

But building great mobile apps with React Native isn’t just about knowing React.

You need to understand:
• App architecture and state management
• Performance optimization and rendering
• API and backend integration
• Offline-first strategies
• Push notifications and background tasks
• Native modules and platform-specific behavior
• Security and data protection
• Automated testing and CI/CD
• App Store and Play Store deployment
• Monitoring, debugging, and production reliability

The interesting challenge is deciding what should remain cross-platform and what should be native.

That decision can have a huge impact on performance, maintainability, development speed, and the long-term health of a mobile codebase.

I’d love to hear from developers who are actively building production apps with React Native:

If you were starting a large-scale React Native app today, what architectural decision would you make differently than you did a few years ago — and why?

DEV Community: Kane Lim

Next.js + Node.js: Where Do You Draw the Line?

Mobile Development Is Changing Fast — Is React Native Ready for What’s Next?