Every Next.js app starts the same way. A few routes, a clean folder tree, and an easy-to-understand and maintain app. Then it grows. A year in, as the app scales the picture is different, your Next.js codebase is now: Hundreds of pages, routes and components. Every feature's code is scattered across
Every Next.js app starts the same way. A few routes, a clean folder tree, and an easy-to-understand and maintain app. Then it grows. A year in, as the app scales the picture is different, your Next.js codebase is now: Hundreds of pages, routes and components. Every feature's code is scattered across these elements, making it a hassle to maintain or debug these features. Multiple teams and devs end up editing the same files, wasting time on conflicts, regression testing, and reinventing the wheel. Both Devs and AI tools struggle to read across scattered code. No reusability, every feature coded in one app is not easy to reuse in other apps. Development slows down, since much of the time spent on new features goes into reading and updating scattered code. If you've only worked with Next.js, you'll probably reach for Multi-Zones or microfrontends, but you already know those are a pain to set up and maintain. If you've worked with other frameworks like Nuxt or NestJS, or even non-JS frameworks, then you probably know that modular architecture is the solution. In most other frameworks, you split code by feature. Each feature is a module that isolates all its logic, making it easier to maintain, debug, scale, remove, and reuse. In this article I will go over why this modular architecture is the best solution to adopt in your Next.js app, and also discuss the next-modular package I've developed to make Next.js support a modular architecture. Here is a comparison of the three different approaches for app scalability Now let's see why the first two fall short on the rows above, and how modular answers each one. As you already know, Multi-Zones splits your app by URL. Each area of the site becomes its own Next.js app. A proxy in the root app then rewrites paths to the right one, so it all looks like a single site. The catch is that you are now running several separate apps to solve what started as an internal code problem. Each one is set up, built, deployed, and maintained on its own. That is a lot of operational weight to take on. And you don't really get much back for it. Sharing state, logic, or context across sections takes extra plumbing every time, because nothing is truly shared. Moving between sections is a full page redirect. Worst of all, it doesn't fix the original problem. A section like auth is still one big app, and inside it your features are just as scattered as before. Multi-Zones splits the site, not your features, so the mess you set out to clean up is still there. AI and devs also have to read and understand all zone apps to understand how to work on features or maintain existing ones. Microfrontends go further. You split the product into fully separate apps. Then you stitch them back together in the browser at runtime. Sharing state, logic, and context across apps is painful. You even have to hand-wire shared React, or every app ships its own copy of it. The cost is steep. Reuse still means shipping a whole app, and navigation between them is still a full page redirect. On top of that, all the extra machinery makes it the hardest of the three to reason about. That goes for you and your AI tools alike. Modular doesn't split the app. It splits the code inside one app, by feature. A module is a self-contained folder that holds everything one feature needs, its pages, API routes, components, and logic, and plugs into your app through a single config entry. // modules/checkout/src/index.ts import { defineModule, route } from 'next-modular'; import * as cart from './routes/cart'; import { checkoutHandler } from './server/api/checkout'; export const checkoutModule = defineModule({ name: 'checkout', basePath: '/checkout', routes: [route('/cart', cart)], apiRoutes: [{ path: '/checkout', handler: checkoutHandler }], }); Every downside that hurt the other two flips here. Setup and maintenance stay easy. There are no extra apps and no extra servers. A feature's pages, API, and logic all live in one module folder, so the split follows your features instead of your URLs. Shared state, logic, and context just work. Nothing crosses an app boundary, so navigation stays fully in-app. Reuse is simple too. Copy the folder into another project, or publish it and install it. An auth module you built for one product drops into the next with a single install and one line in the config, no rewiring routes or copying scattered files. And because a feature lives in one place, both you and your AI tools can actually read it and maintain it with ease. There is one trade to be aware of. You give up independent deploys, everything ships as a single app. For most products that is the right call, but if separate teams truly need their own release cycles, that is the one thing modular won't give you. Next.js doesn't support modules on its own, which is why most people end up reaching for Multi-Zones or Microfrontends. That's the gap next-modular package fills. You define a feature as a module: //./modules/my-module/src/index.ts import { defineModule, route } from 'next-modular'; import * as dashboard from './routes/dashboard'; import { helloHandler } from './server/api/hello'; export const myModule = defineModule({ name: 'my-module', basePath: '/my-module-path', routes: [ route('/my-page', dashboard), ], apiRoutes: [ { path: '/hello', handler: helloHandler }, ], middleware: { handler: myMiddleware, global: false }, }); Then register it in one config file: // modules.config.ts import { myModule } from './modules/my-module/src'; export const modules = [ myModule({ enableFeature: true }), ]; Under the hood, two catch-all routes do the wiring. One sends page requests to the right module. The other sends API requests to the right handler. A middleware proxy runs each module's middleware. You write features, and next-modular routes them for you. You don't have to rewrite anything to get started. next-modular sits alongside the regular app/ router, so you can adopt it incrementally, moving one feature into a module at a time while the rest of your app keeps working as is. There's also a CLI to set it up and add modules: npx next-modular init // sets up your project to use next-modular npx next-modular create --name my-module This next-modular package was my attempt to give Next.js the modular architecture that developers on other frameworks have taken for granted for years. you can read more about it here: https://sweetscript.github.io/next-modular/ https://github.com/sweetscript/next-modular In addition, The idea with this package is to also allow developers to contribute to it and create a public registry of Next.js plug & play modules ready for other developers to use. Just like Nuxt does with its modules registry. To be clear, modular isn't always the answer. If you genuinely have many teams shipping on their own schedules and the infrastructure to run separate apps, microfrontends still earn their keep. But for the far more common case, a single product with scattered code, modular is the lighter and more maintainable path.
Key Takeaways #
- •Every Next.js app starts the same way
- •This story was reported by Dev.to , covering developments in thedev space.
- •AI advancements continue to reshape industries — read the full article on Dev.to for complete coverage.
📖 Continue reading the full article: