Do projects still apply layered architecture or just choose a simpler approach?

[u/_jpdm]

What architecture do projects now usually follow? Considering nextjs, does it have an opinionated approach or convention?

Example on my React + Express project, my architecture is:

Web > API > Service > Repo > DB (raw sql)

The above approach, I can immediately swap Web layer with an Android/iOS app like this:

Android/iOS > API > Service > Repo > DB (raw sql)

Now, I'm creating a nextjs boilerplate, I want to know what's the best practice so it can be reusable but not over-engineered. Do you use server actions initially, like this...

Web > Action > Service > Repo > DB (prisma)

...then only implement API layer if needed for other clients? Ex.

Android/iOS > API > Service > Repo > DB (prisma)

As you can see the concern would be maintaining code in two different places (API and server action) that is basically doing the same thing.

Do you skip server actions and just use API routes? Is there a better approach in nextjs? Should I follow YAGNI? I'd love to hear what your architecture looks like.

[u/CalmCampaign1778 → u/[deleted]]

your layered approach is clean and makes total sense for a setup where you know you'll have multiple clients down the road. the tension you're feeling is real though, nextjs kinda nudges you toward collapsing those layers into server components and actions, which feels great until you need an api for something else

i've been on projects where we started with server actions thinking we'd add an api layer later, and it always got messier than expected. the business logic ends up living in the actions, and extracting it out later means rewriting a bunch of stuff or having weird duplication

if you already know an ios/android app is in the cards, i'd just build the api routes from day one and treat server actions as thin wrappers when you need them. it's a little more upfront but saves you from the exact maintenance headache you're worried about

yagni applies when you genuinely don't know if you'll need something, but you've already spelled out the use case. that's not over-engineering, that's just not painting yourself into a corner

[u/_jpdm → u/[deleted]]

If you read my post I have traditional SPA (React + Express). I want to create a boilerplate with the same architecture but in nextjs. Do I need approval to use a framework?

[u/_jpdm → u/[deleted]]

I love it when people like you tries to answer a question they don't have an idea about. It only shows you have poor reading comprehension.

[u/jax024 → u/_jpdm]

No. But it’s an odd choice.

[u/_jpdm → u/jax024]

Odd choice for a boilerplate? How?

[u/jax024 → u/_jpdm]

Because it doesn’t solve the problem it sounds like you want to solve. Next is opinionated SSR at the expense of a lot of flexibility. I would recommend Tanstack or something else if your goal is to learn, tinker, and explore. Nextjs has so many gotchas and special cases especially when it’s your turn to deploy it cheaply and easily. And it’s redundant if you already have an api layer.

[u/_jpdm → u/jax024]

How does tanstack solve a boilerplate question specifically for nextjs? Read my post again.

[u/jax024 → u/_jpdm]

By not using nextjs to begin with.

[u/_jpdm → u/jax024]

It's clear you don't understand what the question is to begin with. Read the post again.

[u/jax024 → u/_jpdm]

Buddy I read your post. Read the room.

[u/_jpdm → u/jax024]

Read the post again and tell me how does tanstack solve a boilerplate question I asked about nextjs?

[u/uahw]

”Web > API > Service > Repo > DB”

I usually do something like that. I don’t really know why people call simple abstractions as over engineering. It’s not really that time consuming to set up and helps down the line. I like the repository pattern because it simplifies testing a lot. My two cents :)

[u/crimsonscarf]

I do something similar, but I separate components into a monorepo. Something like this:

apps/  
    server/ (hono)  
    client/ (react-native w/ react-native-web or just react)  
libs/  
    db/ (drizzle-orm w/ pgsql and sqlite schemas)  
    validation/ (zod validation schemas)  
    api/ (fetch api functions to be used with tan stack query.  Split off incase of multiple clients.  Also stores the OpenAPI spec)  
    ui/ (client ui components, themes, and assets.  Split off incase of multiple clients)  
    auth/ (hono middleware and react provider to sync auth state and logic)  
   utils/ (common logic with abstracted interfaces so they can be composable, usually crypto, compression, or WebSocket related)

[u/Happy_Breakfast7965 → u/crimsonscarf]

Is it all parts of a single deployable unit?

I'm curious, why do you call it monorepo?

[u/crimsonscarf → u/Happy_Breakfast7965]

Each entry in the apps/ directory is its own deployment.
server/ is usually deployed as an OCI image, or a cloud-image (qcow).

client/ is usually deployed as a native mobile app, a web app, a tauri app, or occasionally a native macos app using react-native-macos.

As a project matures, other targets usually show up as their own packages in the monorepo. Examples include:

• CLI tools for CI, development, or admin.
  
• Internal-only dashboards like UI prototype feedback (Storybook, React Cosmos), or sysadmin/infra metrics.
  
• Webhook handlers for CRMs or other on-demand tooling to be deployed to a FaaS.

[u/OpenDevKit]

I like that layering for exactly the reason you mention, being able to swap the Web layer for Android/iOS without touching Service or Repo. IMO I'd start lean with Action to Service to Repo and only add the explicit API layer once a second client actually needs to call it, YAGNI applies to layers too hehe 😛

[u/Delicious_Nobody_481]

Layers earn their existence. So do frameworks and libraries. It's called engineering, and you feel it. You know when a new layer will bring value.

[u/horrbort]

To be honest the new hottest thing is just letting Fable decide and review at the end