#Next 16 Project Structure (App Router)

1 messages · Page 1 of 1 (latest)

wispy thicket
#

Hi everyone,

I've been trying for days to figure out the best project structure for my Next.js app using the App Router. What do you think of the structure shown in the image? What structure do you use, and what would you recommend?

For context, the project is medium-to-large scale, and this is my main stack:

  • better-auth
  • shadcn/ui
  • react-query
  • react-table
  • prisma
  • react-hook-form

Any advice or suggestions would be greatly appreciated!

immagine_2026-03-26_091726557.png
lone latchBOT
#
Post created!

🔎 This post has been indexed in our web forum and will be seen by search engines so other users can find it outside Discord

🕵️ Your user profile is private by default and won't be visible to users outside Discord, if you want to be visible in the web forum you can add the "Public Profile" role in id:customize

✅ You can mark a message as the answer for your post with Right click -> Apps -> Mark Solution
(if you don't see the option, try refreshing Discord with Ctrl + R)

wispy thicket
tall mortar
#

first suggestion which I'd give is to use drizzle instead of Prisma, you'll get a performance boost

tall mortar
#

In your context, you could maybe like create a folder for each feature and group all the queries there

wispy thicket
# tall mortar and for queries or mutations, I like to structure it like this.

Thanks for sharing! I actually used a similar structure in the past, but I found it becomes hard to manage and maintain once you start having 10–20 features. For each feature, I usually have:

  • components (feature-specific components)
  • hooks (data fetching with react-query)
  • utils or lib (business logic or reusable code)
  • server (all server-side logic)
  • server/actions (mutations using server actions)
  • server/queries (database queries with prisma, server-only files)
  • api (fetching from API endpoints)

One problem I ran into was where to put utility functions or business logic shared across multiple features. To solve this, I created an /entities folder that contains all features with shared code. For example:
/entities/timesheets/ |-- /types # shared types |-- /lib or /utils # business logic usable by multiple features

I also had to split the /lib folder into /core and /shared:
/core contains all core app logic like authentication, prisma, Stripe, etc.
/shared contains all shared code like reusable components, hooks, utils, API handlers, etc.

So basically, I’m looking for a project structure that is optimized and scalable for larger projects.

tall mortar
# wispy thicket Thanks for sharing! I actually used a similar structure in the past, but I found...

Personally, I like to split my frontend and backend into different folders, such that lib folder contains mostly backend components like actions.

And for frontend components , I prefer to add it like @/components/{featureName}/ and all components inside.

for hooks, since hooks are usually reused across multiple pages/components, I prefer to store them like @/hooks/{hookName}.ts if less in number, or organize in sub folders.

tall mortar
# wispy thicket

and I don't really think hooks should be inside mutations, if hooks are reused, consider storing it inside @hooks/

wispy thicket
# tall mortar Personally, I like to split my frontend and backend into different folders, such...

Previously, I used this structure:

/features/feature-1
|-- /server
|   |-- /actions        # server actions
|   |-- /queries        # database fetches with Prisma
|-- /components         # reusable components for the feature
|-- /hooks              # hooks for queries/mutations with react-query
|-- /lib and /utils     # business logic and utilities
|-- /api                # API calls used by react-query hooks

The problem I ran into was about shared business logic or utils across multiple features, since it’s not ideal to import files directly between features. To solve this, I created an /entities folder that contains all the business logic and utils for each feature, so they can be imported wherever needed—even across different features.

How do you usually handle this? If you have numerous features (10–20), each with many files (hooks, API, components, constants, server actions, server queries, etc.) and some shared code, how do you organize it?

Thanks so much for the support you’ve been giving!

tall mortar
#

oh wait, I got a bit confused

tall mortar
#

How do you usually handle this? If you have numerous features (10–20), each with many files (hooks, API, components, constants, server actions, server queries, etc.) and some shared code, how do you organize it?

For this really, What I'd do is I'd basically group features by a category or domain

#

for e.g. if a feature is finance related, I'd put it under the finance folder and so on, for each feature

#

and similarily for shared entities

tall mortar
wispy thicket
tall mortar
#

I wouldn’t suggest you to look at discordjs template much, as that’d be just an elementary level example compared to this case

wispy thicket
tall mortar
#

which basically exports everything inside the folder/subfolders, so its easier to import

wispy thicket
tall mortar
#

then its good to go

#

can u mark my message as a solution

icy joltBOT
# tall mortar > How do you usually handle this? If you have numerous features (10–20), each wi...
Mark an answer as the solution

To mark the message as solution:

  1. Hover over the message you want to mark as the solution.
  2. Right click the message Click the three dots that appear on the right side.
  3. You'll see a menu which should have the option of Apps. Hover Over it.
  4. Click on the Mark as Answer option.
    Note: If you don't see the Mark as Answer option or Apps option, restart/update your discord app!
Requested by Anay-208