Why use Turborepo over Nx
In general or/and for Next.js specifically. I've seen Theo talk about Turbo but when I tried it, it was painful because of all the ESLint errors in the default repo it created. Nx is way richer in tools and benchmarks show that it's faster than Turbo, although I'm not sure if that's still the case. What benefits Turbo has other than being simpler for smaller projects?
5 Replies
GitHub
GitHub - endalk200/create-t3-nx: Clean and simple starter repo that...
Clean and simple starter repo that uses t3 stacks like NextJs, Tailwindcss, NextAuth, Prisma, tRPC and zod with Nx monorepo worksapces. - GitHub - endalk200/create-t3-nx: Clean and simple starter r...
@endalk200 Thanks for creating this repo!
I see that the api package is not completely independent.
If I’ll have more then one FE client it will create some weird scenarios, is there a way to run tRPC backend with next independently?
Yes. There is a way of doing that.
The first thing I wanted to do is to be able to run the whole stack in Nx workspace. After that there are couple of things I am thinking for a second pass.
Not sure what the community is willing to try out though.
I regularly work in huge codebases and there is code architecture that we use internally that makes everything great to work in.
.
├── apps/
│ ├── nextjs-app
│ ├── mobile-app
│ ├── docs site
│ └── ...
└── libs/
├── shared/
│ ├── data-layer/
│ │ └── libs...
│ ├── feature-layer /
│ │ └── libs...
│ └── ui-layer/
│ └── libs...
├── nextjs-app/
│ ├── data-layer/
│ │ └── libs...
│ ├── feature-layer/
│ │ └── libs...
│ └── ui-layer/
│ └── libs...
└── mobile-app/
├── data-layer/
│ └── libs...
├── feature-layer/
│ └── libs...
└── ui-layer/
└── libs...
Something like this
Wow thanks for the detailed reply. I’m asking about this because Im stuck on this for almost two days now 😬 - trying to run the api as a stand-alone with nextjs.
Btw, @julius just reasoned that this will be unnecessary complexity for most users, and it makes sense only when you have multiple apps consuming the same api.
Exactly.
I think of the t3 community is pulling the stack to two different ends one for simple projects with little dependencies and complexity. The other for larger codebases where you have many applications.
A library that contains a code that implements specific feature.
Let's say you have feature a in your app and for that feature you need to write presentational UI components (ui-layer), data layer like fetching data for validation or any busing logic (data layer).
feature layer brings those together. That increased our onboarding process and productivity in our codebase.
.
├── apps/
│ ├── nextjs-app
│ ├── mobile-app
│ ├── docs site
│ └── ...
└── libs/
├── shared/
│ ├── data-layer/
│ │ └── libs...
│ ├── feature-layer /
│ │ └── libs...
│ └── ui-layer/
│ └── libs...
├── nextjs-app/
│ ├── data-layer/
│ │ └── libs...
│ ├── feature-layer/
│ │ └── libs...
│ └── ui-layer/
│ └── libs...
└── mobile-app/
├── data-layer/
│ └── libs...
├── feature-layer/
│ └── libs...
└── ui-layer/
└── libs...
```