I'm a fan of feature oriented directory structures...

Instead of...

    tests
      auth
        login.test.ts
    controllers
      auth
        login.ts
    components
      auth
        login.tsx
    ...

You would have...

    feature
      auth
        login
          login.data.ts
          login.data.test.ts
          login.controller.ts
          login.controller.test.ts
          login.form.tsx
          login.form.test.ts
          ...

That, in my opinion should include tests... You can have shared components, etc... or break up sub-projects.. but within a given project, I prefer features/concerns over class/data type.

edit: In the above case, controller is really a higher order hook along with a higher order function component that will get call the hook, then pass the state to the separate component for render/events.

If you're doing server components, may want something similar but different depending on architecture or out of the box structures.

Check out Tao of Node and Tao of React. It has worked pretty well for us, and is applicable in my opinion to other stacks as well, not just Node.

https://alexkondov.com/tao-of-node/

https://alexkondov.com/tao-of-react/

Usually when I see someone else's repo, the structure doesn't fit my needs. My favorite pattern is putting everything into a single file until there's a clear reason to split it up, at which point the best structure will be obvious.

One thought that is likely to be controversial... Prefer simpler and flatter directory structure over heavily nested and over-organized directory structure.

It's annoying to have a slight error in your import (ie features/segment/part/buttons/MyButton should be features/segment/portion/buttons/MyButton)

I've found through trial and error it's better to just have components/MyButton, maybe another level down

Remix has stacks to get started quickly: https://remix.run/docs/en/main/guides/templates#stacks

It’s probably not answering all your questions, but https://manuel.kiessling.net/2021/05/02/tutorial-react-singl... might be worth a read.

Also, although not React/Node, the thoughts laid out in https://manuel.kiessling.net/2012/09/28/applying-the-clean-a... have served me well over the years.

A well structured pnpm monorepo and a plugin system / architecture has made all the difference for us at Lowdefy [0].

Additionally we’ve architected a way to build complex web apps using config - not everyone’s cup of tea, but with a small team we are building a LOT of complex apps for customers. We are really happy with how this is scaling and we have all the flexibility we need on project.

The config first approach might be controversial, but have a look at the Lowdefy repo, after a few years of iterations it works well for us.

https://github.com/lowdefy

You can check out civitai's repo if you want smth for NextJS: https://github.com/civitai/civitai

Found it pretty useful for my usecase at least since most of my tech stack aligns with them, along with the component framework they use(Mantine)

I'd say start with layers and over time evolve the repo.

For example, http, service, and repository layers. http has your request handlers and you parse those input DTOs or whatever here and call service. service has your business logic, and it calls out to repository (data layer) and once its done it returns the resulting DTO to http which just sends the response.

Over time you'll probably have issues where certain layers are overlapping in functionality. at this point you might want to try out features but this is going to blow out how much code you have.

I'd recommend focusing on solving the customer's problems without going insane.

If you don't care about your employer or you have a clueless manager (90% of managers out there) and just want a promotion, refactor a repo that's already working (even if not optimally tidy) to be 5x more complex and then get a new job.

When I contributed to Foxglove Studio, a robotics data visualization tool built in React and Electron, I found the codebase very easy to navigate. Without much prior JavaScript/TypeScript/React experience, I was able to prototype several new fairly sophisticated features. They've nicely decomposed the code into libraries, with just about the right level of abstraction to make it easy to extend. And given that it's built for visualizing streaming data, they've got performance figured out.

Unfortunately they ceased developing it in the open, but there's a lot to learn from the v1 codebase, and other related projects that continue to be open source.

https://github.com/foxglove/studio/tree/v1

I think there is a fair bit of personal tastes in the answers to these kinds of questions. Personally, I've become a fan of Josh Comeau's "delightful React file/directory structure" [1].

I think it makes a ton of sense, but again, I suspect there's a fair bit of personal preference in these kinds of things.

I'm eager to see what other styles and architectures people suggest!

[1] https://www.joshwcomeau.com/react/file-structure/

After many nodejs app iterations this will be my next nodejs architecture:

sql statements in ./sql/*

endpoint functions in ./endpoints/*

router files in ./routes

Subdirs under those that group things logically for that app

Auth functions in a separate server called by caddy forward auth like checkpoint401 which I wrote

User flow functions in a separate server like identoro which I wrote

Data validation in a separate server like youvalidateme which I wrote

I write big Postgres stored functions/procs and minimal sql in node

I gotta say though I’ll probably use Golang instead of node going forward, after building many node apps.

This one: https://github.com/nodejs/nodejs.org

You can take a look at: https://github.com/ixartz/SaaS-Boilerplate, it should give you some inspiration to structure your React apps with folder structure, component breakdown.

Anything that doesn’t use default exports.

Even though I don't love Next.js and file-based routers in general, I'm a big fan of the cal.com repo: https://github.com/calcom/cal.com

Monorepo, modern packages, and the architecture seems well-considered.

This is a template of a well architected react app I came up with having developed quite a few https://github.com/venil7/react-open-architecture

This repo comes to my mind: https://github.com/outline/outline

I keep this: https://github.com/generalbots/botserver.

The React docs give some nice ideas. I organise with features and it honestly works so well for my needs but experimentation is so key with figuring out.

Is this React projects? Or Node.js projects?

Or projects that use both React and Node.js?

Use clean architecture.

you cant well architect react or node.js code lol.